Boost logo

Boost :

Subject: Re: [boost] Boost.Algorithm design question
From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2011-10-06 19:40:40


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? Are we making that requirement an absolute one that trumps
useful functionality? If so, why? It seems unnecessarily puritan to me.

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

Regards, Phil.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk