|
Boost : |
From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-22 12:04:22
On Thu, Oct 23, 2003 at 01:13:49AM +1000, Thorsten Ottosen wrote:
> "Beman Dawes" <bdawes_at_[hidden]> wrote in message
> news:4.3.2.7.2.20031022084437.031144a8_at_mailhost.esva.net...
>
> > Short term that's probably OK. Long term users may want to use certain
> > algorithms with containers which don't full meet the Sequence requirement.
> > Why shouldn't some of the algorithms work on an Associative container for
> > example? Or a home-made container which supports insert but not erase or
> > visa versa.
>
> I think it might be all-right for a string library to focus on strings
> instead of arbitrary containers.
>
> There is an issue that would be nice to discuss, though. As an example, take
> the function all(). Should it
> be part of the string library or a more general algorithm library? Currently
> it is also implemented
> in the sequence_algo part of the sandbox. My point is where should we draw
> the line between
> a string algorithm and a generic algorithm? IMO, all() should not be part of
> a string library, but other cases
> might not be so clear cut.
Problem is, that there is nothing like algorithms library currently in the boost.
Once, the other libraries will be reviewed, some reordering can be performed.
It is hard to make a border between two countries, when there only one.
all() predicate was added to the string_algo library, because, there was
a request to handle classification of a string. (i.e a sequence variant of
std::isspace and etc). all() with a set of classification predicated was a natural
choice for this task.
Pavol
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk