Re: [eigen] Namespaces

[Benoît Jacob <jacob@xxxxxxxxxxxxxxx>]

On Thursday 11 October 2007 11:41:39 Cyrille Berger wrote:

> On Wednesday 10 October 2007, Benoît Jacob wrote:

> > we initially used namespaces, but switched to prefixing recently. The

> > reason is that namespace offer little protection as most users will want

> > to be "using namespace". For instance look at the EiObject class. Without

> > prefix, it'd be Object. A much too common name. If we encapsulate it in a

> > namespace, it becomes Eigen::Object, which is safe, but... most users

> > would like to "using namespace Eigen" and if some class is called

> > "Object" then "using namespace" is not an option, because "Object" is a

> > too polluting name.

>

> In that case the compiler would return an error, it's hardly a problem.

I think that it is a problem! For, once the compiler does return an error, what is the next step the programmer does? He has no choice, he gives up "using namespace". So he has to write Eigen::Something everytime he adresses a Eigen object. So this amounts to prefixing -- only with a much more annoying prefix: "Eigen::" vs. "Ei".

The only advantage of namespaces versus prefix is the possibility of doing "using namespace". Other than that, namespacing is just prefixing. Both in the source code and in the generated object code.

>

> > Look at what Qt does. Qt classes are not encapsulated in any namespace,

> > instead they have the Q prefix, like "QObject".

>

> Qt was first release at a time when namespaces were not well (if at all)

> supported by most C++ compiler.

Qt1 was. Qt4 uses some namespaces, but not to encapsulate the whole public API. Qt uses namespaces where it makes sense only, that is, for smaller parts of the API where the user doesn't feel the need anyway to "using namespace".

It would be a very bad idea for Qt to go for namespaces instead of prefix, i.e. "Qt::Object" instead of "QObject", for the same reason that I mentioned for Eigen2.

Same for QList, QVector, QThread, QApplication...

For these reasons, it's generally a wrong idea to encapsulate a whole public API in a namespace.

Good uses for namespaces fall into 2 categories:

1) cases where one doesn't feel the need to "using namespace". That is, small namespaces encapsulating only a small part of an API. Example: the Qt namespace.

2) cases where one doesn't need to care about namespace pollution, that is, non-public API. Example: an internal library in a large application project.

An exception is the c++ standard library (namespace std). This is an exception because as the "standard library" it has a licence to pollute. One just has to accept that names such as "string", "list", "vector" are already taken by the std library.

But people then think, "hey, the standard library uses a namespace instead of a prefix, so this must be the way to go for my own library", and that is wrong.

Cheers,

Benoit

Attachment: signature.asc
Description: This is a digitally signed message part.