Re: [boost] [review][sort] Formal review period for Sort library begins today, November 10, and ends Wednesday, November 19

Subject: Re: [boost] [review][sort] Formal review period for Sort library begins today, November 10, and ends Wednesday, November 19
From: Steven Ross (spreadsort_at_[hidden])
Date: 2014-11-14 21:34:17

Niall,
On Fri, Nov 14, 2014 at 7:31 AM, Niall Douglas
<s_sourceforge_at_[hidden]> wrote:
> On 10 Nov 2014 at 0:39, Edward Diener wrote:
>
>>      - What is your evaluation of the design?
>
> It's okay. I would prefer a design where there is a sorted_view which
> if std::copy gives an actually sorted copy. Obviously one would then
> specialise that scenario with a more directly optimised
> specialisation, and you'd also have the API presented here which
> looks like std::sort().

I'm not sure exactly what you mean by a sorted_view.

> I'd also prefer to see fallback implementations for less than random
> iterators, right down to forward only iterators.

To sort at reasonable speed requires either random access iterators or
allocating a deep or shallow copy of the data.  I could write a simple
wrapper to create a vector of iterators pointing to the input data,
sort the iterators, and then use them to permute the original list,
but what's the use case?

> Lacks scaling graphs near front so people can quickly evaluate
> usefulness compared to std::sort. I believe the author will fix this
> though.
>

Done in the develop branch.

> 2. Exception safety is not obvious, and explicit exception guarantees
> need to be made and stated per API in the documentation.

How about statements like this in the documentation for each of the headers:
Exceptions: Throws if any of the element comparisons, the element
swaps (or moves), the right shift, subtraction of right-shifted
elements, or the operations on iterators throws.