Make an include guard unique

[elfring]

I find that an include guard like “ACO_H” can be too short for the safe reuse of your header file (when it belongs to an application programming interface).

[hnes]

Good point, how about change 'ACO_H' to something like 'ACO_V1_H'?

V1 here means the major version number.

[elfring]

How do you think about to make include guards unique by appending a kind of UUID?

[hnes]

I think 'ACO_V1_H' is long enough.

The compilation errors will be yielded when it is happened (could be very rarely) that there is some other c header file has the exactly same include guard 'ACO_V1H' (because many other 'aco*' macros and prototypes which are defined in 'aco.h' is always required by the 'aco.c' and other libaco application source files).

I'll commit this adjustment soon :-)

[elfring]

I am curious then how often corresponding name space issues will occasionally matter.

[hnes]

How do you think about to make include guards unique by appending a kind of UUID?

I think that kind of solution probably be a little overweight. Imaging that there is a UUID hex in the include guard :D

But maybe one day this would be added into to the new C standard. Be honestly, personally I think this solution is a very good solution.

[hnes]

There is some search results about the "uuid include guard". It has been used on some occasion.

[hnes]

One problem here is, the possible inner api & macros collision (say there is another aco.h which also have some maybe different aco_* macros and prototypes) may still exist even when the include guard is unique. In some cases, I think the compilation errors would be yielded more easily when the two collision aco.h have the same include guard.

[hnes]

People normally would think that the C header file name (say "aco.h") is usually corresponding to the macro name of the include guard ("ACO_H" in this case).

If there is a totally different macro name of the include guard with the file name, it may would delay or even suppress some compilation errors that should be yielded as soon as possible.

So I think it is not necessary to use a different macro name of the include guard in aco.h, let's keep "ACO_H".

(Unless we choose to change the all aco* started macros and prototypes into aco{$UUID}_* in our source files, then the collision naming problems is solved fundamentally... But this kind of solution is only suited for very special and rare situations in real life.)

[elfring]

People normally would think that the C header file name (…) is usually corresponding to the macro name of the include guard ….

The expectations are varying, aren't they?

…, let's keep "ACO_H".

• The probability for name clashes might be low enough also for such an identifier (for a while).
• Other name variants can be safer.

[hnes]

The expectations are varying, aren't they?

…, let's keep "ACO_H".

• The probability for name clashes might be low enough also for such an identifier (for a while).
• Other name variants can be safer.

Yes, I agree with you. So, let's just remain what it is.