TITLE: Bjarne on namespaces

(Newsgroups: comp.lang.c++.moderated, 26 Jan 98)


BONNARD: Valentin Bonnard

 > > >> #include <string>
 > > >> using std::string;


WILDEN: "Mark Wilden" <Mark@mWilden.com>

 > > >Which as far as I understand is even worse for the
 > > >identifier 'string', because it puts 'string' in the
 > > >global namespace.
 > 
 > > Which is exactly what I want. If there is another "string" in the
 > > global namespace, the compiler will tell me, and I can then fix it
 > > further; if not, I've avoided typing "std::string" everywhere when
 > > it's not necessary.


WATERS: Chris Waters <cwaters@systems.dhl.com>

 > Yes.  Personally, I think the standard library *belongs* in the global
 > namespace.  I mean, why not?  I think that the main issues which
 > forced it into its own namespace are, one, the fact that a lot of the
 > standard library is brand new, so existing programs may have
 > conflicts, and, two, it may help encourage others to use namespaces to
 > see that the standard library uses one.


STROUSTRUP: bs@research.att.com (Bjarne Stroustrup)

It is an important library design criteria that designers should live
without too much special pleading. If the language rules are good enough
for users, they should be good enough for standard library designers.

On a less philosophical plane, consider writing a program that is supposed
to use a limited and/or specialized set of facilities to minimize system
dependencies. I may have functions and classes that resemble standard
library facilities, or I may simply want to avoid some standard facilities
because they are unsuitable in some environment where my application should
run. If the standard library is in the global namespace, they are in scope
and people will use them by accident or through ignorance.

Consider also the unsavory fact that many implementors place their own
extensions in the standard headers. Yes, I know that's not allowed according
to the standard (C or C++), but it's a fact of life and *many* users would
be quite upset if facilities they had relied on for years suddenly disappeared
from those headers. I suspect many would curse the standard rather than the
vendor who had locked them in by the extensions. If the standard headers
inject names into the global namespace, you suddenly have these vendor-specific
extensions implicitly available.

With the standard library in namespace std and the <no-h> headers, you know
that you are not polluting the global namespace so that you - and others on
your project - don't accidentally pick up undesired names. If you want the
standard library and the vendor-specific extensions that usually co-exist
with them in the standard headers universally available without qualification,
you can place them in the global namespace yourself. Where practical, I urge
you not to do that.

My views on how to use namespaces can be found in "The C++ Programming Language
(3rd edition)."


WATERS:

 > But, I mean, what's the point of *having* a global namespace if it's
 > always completely empty?


STROUSTRUP:

The global namespace is never *completely* empty. You'll find "main,"
"std," and the users' primary namespaces there.