What if a header that you /need/ to include starts to clash with a name in your
program. Implementations should provide a way by which you can select the
precise standard conformance. E.g. what if someone needs to build a C90
program? It's simpler to have a switch for that in the implmentation than
to update the program.
granted, yes, having to include certain headers to get certain new
symbols to be defined makes some sense.
but, IMO: if one is having lots of name clashes of this sort, then they
are likely facing with a bigger set of naming problems.
personally, I like using a system of naming conventions to try to reduce
clashes (if done well, ideally accidental clashes should be fairly rare,
both within ones' code, and with external code).
probably a big risk is when one's naming convention is something like
"word()" or "generic_words_and_underscores()", since any functions which
just happen to have a matching description will have a risk of clashing.
typically, in my case, this includes prefixing the name of the library
(and often, the component) on damn near everything.
say, when building "foolib.dll" or "foolib.so":
FOOLIB_SomeName (library-scope name);
FOOLIB_Component_SomeName (component-scoped name).
then it is mostly a matter of whether there are multiple libraries named
"foolib" (in turn leading me to use my initials as a prefix for most of
my library names, followed by more letters to identify the particular
library, say "BGBGC", "BGBDY", ...).
typically, a FirstLetterCaps convention is used for all names.
typically, global variables (if used) are all lowercase, typically using
camelCase instead (camelCase is also generally the convention for
struct-field names, but this is much less consistently followed).
internal functions typically also follow the above convention, but are
still lower-case.
other variants (typically used for methods):
libname_object_methodNameCamelCase
libname_component_object_methodNameCamelCase
sometimes, functions include suffixes, generally to indicate either the
argument types or special properties (such as 'I' for Internal, or 'R'
for Recursive). if suffixes are used, typically it is with a similar
convention to that used by OpenGL (3i, 3f, 3fv, ...).
I also sometimes use an OpenGL style naming convention
("prefixCamelCase"), generally for what are intended to be public API
functions (many older cases use all lowercase though).
granted, clashes are not entirely ruled out, for example, both my GC and
Boehm GC use the 'GC' prefix for the public API, differing mostly in
that Boehm typically uses 'GC_' whereas my GC typically uses 'gc' as
lower-case ("gctalloc()" for GC type-tagged allocation, note that
internally the prefix 'BGBGC' is used).
MS tends to use a similar convention for API functions, albeit
preferring to have an uppercase prefix (for example "WSAGetLastError()"
and similar).
also, sadly, sometimes there are exceptions, where due to laziness or
other reasons, shorter names are used, very often this means leaving off
the component or library.
LIBNAME_SomeName, when a component name "should" be included.
or:
Component_SomeName, typically for older code (before I got as rigid
about including the library name).
likewise, in a few cases "unsafe" prefixes have been used, such as
'v2'/'v3'/'v4' for some vector code (because 'v3dot' is a lot easier to
type fairly often than something like 'dyVec3DotProduct' or similar).
or such...
