Boost logo

Boost :

From: Pavol Droba (droba_at_[hidden])
Date: 2004-02-18 08:34:05


Hi,

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:

boost
 - algorithm - common algorithm related stuff
   - string - string algorithms
   - container - container algorithm
     etc.

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?

Suggestions:

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
    namespaces)

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.

Regards,

Pavol


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk