Subject: Re: [boost] RangeEx review
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2009-03-01 10:56:19
Mathias Gaunard wrote:
> Phil Endecott wrote:
>> - It would be good if the docs were explicit about this being a thin
>> wrapper around your existing std::sort, and identifying those algorithms
>> that are not so thin.
> Actually, I believe sort(c) calls c.sort() if it exists.
> So it's not just std::sort.
I don't see any evidence of that in boost/range/algorithm/sort.hpp.
Where should I be looking? This would of course be a useful feature,
and documenting whether it is or is not done would be useful.
>> My point is that std::unique only has its "move duplicates to the end"
>> behaviour because the conventional interface with a pair of iterators
>> doesn't let you change the size of the container. Now that we have a
>> unique() that takes a container we don't need that restriction.
> Not a container, a range.
The fact that the container that I pass is converted to a range can be
considered as an implementation detail for many applications of this library.
There is a lot of stuff in C++ that is more complicated to use than it
could be. We have all got used to how things are and know the reasons
why, but it presents an obstacle to new users. This library reduces
some of this complexity, which is really great. I suggest that we
consider how much further we can go in this direction. Maybe
algorithms that really take containers, rather than ranges, are beyond
the scope of this library. Or maybe not.
> However, uniqued(vec) returns a new lazy range without duplicates (if
> the range is sorted), and unique_copy(vec) returns a new range without
Neither allows me to unique a container in-place though.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk