-
Notifications
You must be signed in to change notification settings - Fork 392
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make an include guard unique #2
Comments
Good point, how about change 'ACO_H' to something like 'ACO_V1_H'? V1 here means the major version number. |
How do you think about to make include guards unique by appending a kind of UUID? |
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_V1_H' (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 :-) |
I am curious then how often corresponding name space issues will occasionally matter. |
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. |
There is some search results about the "uuid include guard". It has been used on some occasion. |
One problem here is, the possible inner api & macros collision (say there is another |
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.) |
The expectations are varying, aren't they?
|
Yes, I agree with you. So, let's just remain what it is. |
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).The text was updated successfully, but these errors were encountered: