Boost logo

Boost :

From: Ed Brey (brey_at_[hidden])
Date: 2000-02-03 11:11:33

I'd like to suggest that we put the cstdint definitions into a nested
namespace, so that this subset can be pulled into a given context all at
once. The boost namespace would also pull all the names in, as per standard
boost practice with this kind of namespace nesting.

Specifically, cstdint, would look like:

namespace boost {
    namespace stdint {
        #include <boost/stdint.h>
    } // namespace stdint
    using namespace stdint;
} // namespace boost

With nested namespaces, the risk of name clashes becomes much lower. Since,
the quantity of names imported is small, and generally, there is a good idea
of how the names will grow. For example, the stdint names follow a distinct
pattern. There is no guarantee that there won't someday be a reason to put
a new name in the namespace that is completely unrelated, but risk becomes
so small, that the savings in code readability may outweigh the near-zero
maintenance. (Note that I'm not trying to say that namespace qualifiers
always degrade readability; indeed, they usually help, IMHO. However, I
find in some repetitive situations (such as making a union with various
types from cstdint), that they get in the way.)

Furthermore, there is a circumstance under which the using directive is
guaranteed to be safe: when only one using directive is active. This can be
a common occurrence, given the right scoping. For example:

void f() {
    using namespace boost::stdint;
    union u {
        int32_t si;
        uint32_t ui;

Even if boost::stdint would someday declare the name u, there would be no

This gets me thinking that maybe there should be a formal write-up of the
theory behind namespaces and how the using directive can be used safely (and
of course how is can be unsafe). I could bring these thoughts together to
do so, if there is interest. But first, I want to make sure that there
aren't any holes in my logic or that someone else hasn't done so already.

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