[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IMP-dev] macro names




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.