From: Pavol Droba (droba_at_[hidden])
Date: 2004-02-18 08:34:05
During the review of the string algorithm library, an issue was raised about the
namespaces for algorithmic libraries in the boost.
The issue has not been sufficiently resolved, and I would like to bring it up to
the discussion again.
Current proposal looks like this:
- algorithm - common algorithm related stuff
- string - string algorithms
- container - container algorithm
Although this seems clear enough, there are some open questions.
1.) Namespace path is quite long. It is not really reasonable to await from
a user to always type boost::algorithm::string::trim.
"using namespace" directive is not always a viable solution. And even if it
would be, a user would have to specify several of them to use whole algorithm
library (what could not so uncommon, in my opinion)
Namespace aliasing is one of possible solutions, but again, one would have
to alias every algorithm sub namespace.
2.) It is not clear if what should go into boost::algorithm namespace and what to more
specific ones (like boost::algorithm::string). This is specificaly an issue of algorithms,
that logicaly belong to various categories.
An example would be "all" algorithm. It is generic enough to not be contained
in the string library. But on the other hand, together with classification predicate,
it is essencial for the string processing. Should it go to algorithm::string,
algorithm::container, plain algorithm or somewhere else?
1.) One possibility would be to relieve the idea of algorithm subnamespace and put everything into
boost::algorithm namespace. Benefit would be simplier namespace specification and less
suprises about where is a particular algorithm. Disadvantage can be a possibility of nameclashes
and poluted namespace.
2.) Another option would be to use subnamespaces, but to propagate user-level interface names
to boost::algorithm using "using" directive. In this alternative, there is still an open
question (2). (i.e. to define more precisely the policy for putting algorithms/classes into
3.) Let everything in subnamespaces and identifying the problem(1) as irelevant.
4.) Some other idea, I don't know yet about.
Your ideas/optinions are welcome.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk