Re: [boost] Re: Re: Re: algorithms namespace

From: Pavol Droba (droba_at_[hidden])
Date: 2004-02-19 04:28:53

On Thu, Feb 19, 2004 at 07:37:38PM +1100, Thorsten Ottosen wrote:
> 
> "Pavol Droba" <droba_at_[hidden]> wrote in message
> news:20040219074546.GF11201_at_lenin.felcer.sk...
> [ambiguity not an issue]
> > Please give me an example of an algorithm, that can be threated
> differently
> > for strings and for containers. If there would be something like that (I
> don't
> > see any), than is would make sense to use different names, rather then
> just
> > different namespace. Otherwise, a user can get quite confused.
> 
> The problem arise if there is, let's say, four versions of a particular
> algorithm.
> Two works on iterators and two works on containers and there might be other
> arguments too. It certainly clashes in
> the container algos so that we can't have unqualified calls but must use
> boost::XX and std::XX.

Well, this is exatcly what I have pointed out. If there is such an ambiguity,
that the names should be different.
It could realy make some nasty problems, if you accidentialy use the wrong overload,
just because you forget to specify the correct namespace. (For instance if you 
are using "using namespace" directive)

I understand the current problem between std:: and boost:: algoritms. 
However, this problem is because, you are replacing the algorithms already defined
in the std:: . And so the conflict pops up.

I assume, that in boost::algorithm, most of the algorithms will use collection_traits
of something similar, so there will no be a reason for the problems like this.

Also, I doubt, that there will be an algorithm contained in two different algorithm
libraries, just with a different signature. It should not be, by design.

Regards,

Pavol

BTW: I just thought, when we are speaking about the algorithm namespace and libraries,
     It would make sense to consider if some libraries already contained in boost should not be moved
     to the algorithm namespace as well. For instance regex library might be a good candidate.