Boost logo

Boost :

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" <> wrote:

> Dave Abrahams wrote:
>> on Thu Oct 06 2011, "Phil Endecott" <> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at