Boost logo

Boost :

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-07-09 15:35:40


Ed Brey wrote:
> "Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote:
> > FWIW, MPL provides a special header, "boost/mpl/alias.hpp",
> that user can
> > include to get an equivalent of
> >
> > namespace {
> > namespace mpl = boost::mpl;
> > }
> >
> > definition, e.g.
> >
> > #include "boost/mpl/list.hpp" // for boost::mpl::list
> > #include "boost/mpl/alias.hpp" // namespace alias
> >
> > // now we can use 'mpl::' instead of longish 'boost::mpl::'
> > typedef mpl::list<char,short,int> types;
>
> This technique is prone to clashes that a namespace alias at
> global scope is.

Well, of course. Ultimately you always, in one way or another, are going to
be responsible for assigning the unique global namespace aliases for your
particular project. What the alias header does is

1) it keeps you away from undefined behavior;
2) it keeps others from the details of how it does it;
3) it saves you typing.

[snip]

> This demonstrates how having an alias.hpp file doesn't really
> solve anything in the general case, but rather can only help
> mask the problem. The one case where alias.hpp could be
> useful it if it is only included from a .cpp file, rather than a .hpp
file;
> however, the potential for misuse it too high to warrant a header file
> to save two lines of code.

What misuse?

> My experience has been that the way to robustly solve the
> alias problem is to centralize the definition of aliases.
> Each namespace has its own center. So if you have a
> component that lives in the namespace MyComponent, you have a
> single set of header files that include and alias various
> resources. For example, if several files in MyComponent use
> mpl, you would create a header called mpl.hpp, which would
> look like this:
>
> // 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.

Aleksey


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk