Boost logo

Boost :

From: Ed Brey (brey_at_[hidden])
Date: 2002-07-09 16:29:50

"Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote in message

> > // MyComponent/mpl.hpp
> > #include <boost/mpl/list.hpp>
> > namespace MyComponent {
> > namespace boost::mpl;
> > typedef mpl::list<char,short,int> types;
> > }
> In real life I, as a user (and, I think, many other users), would like the
> "mpl" (or "ublas") name to be a _global_ namespace alias. Yet we definitely
> wouldn't like our programs to start behave in some strange ways when someone
> unwillingly introduces a conflict which cannot be detected by the compiler.
> The only way to more or less guarantee this is to use the
> "alias-in-the-unnamed-namespace" technique consistently through the whole
> project, and the easiest way to guarantee this consistency is to encapsulate
> the safe-guarding mechanism in a header file.

How is having an alias in a global namespace any better than having it in the namespace that you are currently writing code into? If you are writing into the global namespace, then I agree, the global namespace is the right place for the alias.

I understand how the "alias-in-the-unnamed-namespace" technique is useful for preventing clashes that the compiler cannot detect. But why stop there? Why not use a coding system that prevents the clash from appearing in the first place? Even if the compiler detects a name clash, it may be after two conflicting names have been used extensively in (previously) separate pieces of code, meaning that all but one of them will need a large set of renaming.

Looking at the supposed advantages, a centralized approach to name reservation seems to satisfy all the reasons for an alias headers existence:

> 1) it keeps you away from undefined behavior;
And clashes, too.

> 2) it keeps others from the details of how it does it;
There are no details since there is no magic - just a namespace alias.

> 3) it saves you typing.
Without the anonymous namespace magic, there isn't any significant typing.

Boost list run by bdawes at, gregod at, cpdaniel at, john at