Re: [eigen] Namespaces

[ Thread Index | Date Index | More Archives ]

It is also possible to use
  using Eigen::Matrix;
for example. There's no need to unlock the whole namespace.

Kind regards

On Thursday 11 October 2007 12:13:33 Benoît Jacob wrote:
> 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.

Mail converted by MHonArc 2.6.19+