Subject: Re: [boost] Boost.StringAlgo:library defects?
From: Neil Groves (neil_at_[hidden])
Date: 2009-07-29 10:06:45
On Wed, Jul 29, 2009 at 2:58 PM, Mathias Gaunard <
> As I integrated my Unicode library with Boost.StringAlgo, I noticed a few
> - The Finder concept seems inappropriate, since find_iterator<last_finderF>
> can't work as expected. I suggest building left-to-right and right-to-left
> searching directly into the Finder concept.
> - Certain functions that take ranges only take Range& and not const Range&.
> Interestingly enough, in the cases where I've found it does that a const
> Range& would have been enough.
> - Usage of the Finder concept is incompatible with its definition. Indeed,
> finders are passed by const reference, which means the operator() must be
> const, unlike in the examples.
> - Finders are explicitly calling boost::as_literal on the string to search
> for, which I believe should not be their responsibility but that of the
> callee (or not, but I would have expected a rationale at least).
> - Why is there no trim variant that simply returns a sub range of the input
> range? There are only ways to modify the sequence in-place or copy a trimmed
> - Algorithms such as find being pushed in the boost namespace is
> incompatible with, for example, updated version of Boost.Range
> Since boost::algorithm::find is quite different from std::find, it should
> not be promoted to boost::find.
I agree I think we need to review which functions are in the boost
namespace. More troublesome is that the current Boost.Algorithm library has
many pieces of code that are not protecting against accidental ADL.
> Since the library is fairly old (2002), I assume some of these issues are
> Is there any plan to fix them?
Yes, I have started discussion with Pavola about needing to make changes to
improve compatibility with RangeEx. I have submitted a fix for the
accidental argument dependent lookup issues in the current version of
Boost.Algorithm. This resolves several problems that users of both
Boost.RangeEx and Boost.Algorithm are currently experiencing. I will be
making the Boost.RangeEx code implementations in boost::range namespace and
then adding using directives to keep compatibility while providing the
client the ability to disambiguate between the calls. Additionally we will
work together to eliminate redundancy and where necessary take code out of
the top-level boost namespace.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk