TITLE: Use structs to partition the global namespace


(This example taken from "Effective C++" by Scott Meyer, p. 93 - 95. Most
of the text is verbatim. Omissions are indicated with ... and substitutions
are marked with [].)


The biggest problem with the global scope is that there's only one of them.
In a large software project, there is usually a great bevy of people putting
names in this singular scope, and invariably this leads to name conflicts. 
For example, library1.h might define a number of constants, including the
following:
	
	const float LIB_VERSION = 1.024;

Ditto for library2.h:

	const LIB_VERSION = 3;

It doesn't take great insight to see that there is going to be a problem if
a program tries to include both library1.h and library2.h. Unfortunately,
outside of cursing under your breath, sending hate mail to the library 
authors, and editing the header files until the name conflicts are
eliminated, there is little you can do about this kind of problem.

You can, however, take pity on the poor souls who'll have your libraries
foisted on them. By creating a struct to hold your global names, and by
putting your global names inside this struct as static members, you can all
but guarantee that your clients won't have to worry about name conflicts
in the global scope.

	struct MY_GLOBALS {
		// a library-global type
		enum Boolean { FALSE, TRUE };

		// a library-global function
		static Boolean licenseHasExpired ();

		// a library-global object
		static const float LIB_VERSION;
		...
	};

	// As usual, static data members must be
	// initialized outside the struct
	const float MY_GLOBALS::LIB_VERSION = 1.6;

Now when people want to access your global names, they simply prefix them with
the scope name:

	MY_GLOBALS::Boolean b = MY_GLOBALS::TRUE;
	MY_GLOBALS::Boolean oldLicense = MY_GLOBALS::licenseHasExpired();
	cout << MY_GLOBALS::LIB_VERSION;

If somebody else has used globals with the same names as you choose, there's
not a problem, because the competing names will be in a different scope.

However, if there are no name conflicts at the global level, clients of your
library may find it cumbersome to use the fully qualified names. Fortunately,
there is a way you can let them have their scopes and ignore them too.

For your type names, provide typedefs that remove the need for explicit
scoping. That is, for a type name T in your namespace struct G, provide a 
(global) typedef such that T is a synonym for G::T:

	typedef MY_GLOBALS::Boolean Boolean;

For each (static) object X in your struct, provide a (global) reference X
that is initialized with G::X:

	const float& LIB_VERSION = MY_GLOBALS::LIB_VERSION;

You need to ensure that these objects are initialized before they're used.
...

Functions are treated just like objects, but the old use-a-global-reference
trick is much more impressive when applied to functions in your struct, 
because who's ever heard of references to functions? Try to act casual when
you show your colleagues this little number:

	// make licenseHasExpired another name for
	// MY_GLOBALS::licenseHasExpired; also impress your friends
	MY_GLOBALS::Boolean (&licenseHasExpired)() = 
		MY_GLOBALS::licenseHasExpired;

Given these typedefs and references, clients not suffering from global name`
conflicts can just use the unqualified type and object names, while clients
who do have conflicts can simply ignore the typedef and reference declarations
and use the fully qualified names. Because not all the clients of your
library will want to use the shorthand names, you should be sure to put [them
in a different header file.]

The only fly in the ointment is enumerator values, which must still be fully
qualified. Even with the typedef, clients must still write

	Boolean b = MY_GLOBALS::FALSE;

This is unfortunate, and the only way around it is to write macros for the
enumerators:

	#define FALSE MY_GLOBALS::FALSE
	#define TRUE MY_GLOBALS::TRUE

	Boolean b = FALSE;   // use typedef and macro

... some party pooper is sure to point out that ... accessing members of your
struct through the nicely named references costs one indirection per access.
Needless to say, there are applications that can't afford such luxuries,
although the number of programmers who are convinced they are working on such
applications probably far outnumbers the applications where it's honestly an
issue. Still to shut them up ...

	#define LIB_VERSION MY_GLOBALS::LIB_VERSION