On Oct 8, 2008, at 9:52 AM, Ben Webb wrote:
> Daniel Russel wrote: >> We aren't very consistent about macro names throughout IMP. I would >> suggest >> IMP_CORE_BEGIN_NAMESPACE >> IMP_CORE_EXPORT >> IMP_EXPORT > > On the contrary, I think the names are pretty consistent. Namespaces > and > header names are mapped to uppercase, :: is mapped to '', and > CamelCase > case changes are mapped to '_'. Seems that your proposal would either > add an inconsistency (namespace macro IMP_CORE_BEGIN_NAMESPACE > inconsistent with header guard IMPCORE_FOO_H) or a header guard > ambiguity (no way to distinguish Bar.h in the foo module from FooBar.h > in the kernel, since both would map to IMP_FOO_BAR_H). This is why > there > is no space between 'IMP' and 'CORE' in any of the macros. In camel case the case is the token deliminter. If you use underscores the underscore is the token delimiter. In namespaces the :: is the delimiter. We have to use _s is macros, so all the delimiters should map to that.
Of course the full path to the header needs to be in the header guard (IMP_CORE_HEADER_NAME_H) so there is no source of ambiguity unless we are silly enough to start prefixing things in IMP with names that are the same as modules.
For example IMPDLLEXPORT and IMPCOREEXPORT are clearly inconsistent - the DLL should be in both or neither - EXPORT is a different token than IMPCORE at least, so it should have an _ - IMP and CORE are different namespaces so the above comment applies.
> > >> in addition, the __ in the header guard names doesn't add anything >> and >> is technically illegal in C++/C. > > If you have a source for that assertion I'd be happy to remove it. It > actually appears to be quite common usage though (e.g. freetype and > glib2 both do that). For example: http://developer.mozilla.org/En/C___Portability_Guide According to the C++ Standard, 17.4.3.1.2 Global Names [lib.global.names], paragraph 1:
Certain sets of names and function signatures are always reserved to the implementation:
• Each name that contains a double underscore (__) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use. • Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.
So macros (which are always global) get hit.