Re: [boost] Boost.Algorithm design question

Subject: Re: [boost] Boost.Algorithm design question
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-10-06 21:21:05

on Thu Oct 06 2011, "Phil Endecott" <spam_from_boost_dev-AT-chezphil.org> wrote:

> Dave Abrahams wrote:
>> on Thu Oct 06 2011, "Phil Endecott" <spam_from_boost_dev-AT-chezphil.org> wrote:
>
>>> Dave Abrahams wrote:
>>>> I'd like to see
>>>> somebody write the description of the algorithm, including the concept
>>>> requirements.
>>>
>>> Well we can start by copying what the experts wrote for std::find,
>>> can't we?  
>>
>> Who are "the experts?"  The specification that we have in the standard
>> library is not current best practice when it comes to Generic
>> Programming.  I'm not sure who crafted the language, but it's not what
>> we should do today.
>
> Well perhaps we need to step back and decide what we're trying to do
> here.  Are we trying to create stuff that is so "best practice" that
> it's even better than the not-yet-ratified new version of the
> language?  

I guess you missed the news.  C++11 is ratified.  But, yeah, why
shouldn't we do better if we can?

> Are we making that requirement an absolute one that trumps useful
> functionality?  If so, why?  It seems unnecessarily puritan to me.

Just to be completely honest here: I've been wondering the same
thing... maybe I've been poisoned by Stepanovian purity.  

>>> For the non-predicate version it just says "Returns: The first
>>> iterator i in the range [first,last) for which *i==value holds"
>>> (n3242).  
>>
>> Exactly, a pile of syntax.
>
> Back in the "clamp" discussion, I tried to argue that for trivial
> operations I would actually prefer to have a "pile of syntax" rather
> than a free-standing spec.  

It's an interesting idea that trivial things are better described in
terms of their implementations.  *Very* interesting.

> My argument was that for trivial things we actually have the
> implementation in our minds first and then find ourselves trying to
> think of some other way of expressing the same thing in order to write
> down a spec; in the process, we're as likely to make a mistake in the
> spec as we are to make a mistake in the implementation.  Examples:
>
>     clamp(val,lo,hi) = val<lo ? lo : val>hi : hi : val;
>
> vs.
>
>     clamp(val,lo,hi) returns the middle value when (val,lo,hi) are
> ordered according to operator<

Wow, that certainly is stark.  When I try to describe it better in
words, it reads just like your implementation.  But I'm not sure what
that proves.  Swap is a trivial algorithm.  Isn't it best described as
"exchanges the values of its arguments?"

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com