Re: [boost] RangeEx review

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.

>>   unique(vec);

>> 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 
> duplicates.

Neither allows me to unique a container in-place though.

Cheers,  Phil.