On Wed, Jul 29, 2009 at 2:58 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
As I integrated my Unicode library with Boost.StringAlgo, I noticed a few issues:
- 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 one.
- Algorithms such as find being pushed in the boost namespace is incompatible with, for example, updated version of Boost.Range (Boost.RangeEx). 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 known. 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. Regards, Neil Groves