Re: [boost] Boost.Algorithm design question

Subject: Re: [boost] Boost.Algorithm design question
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2011-11-02 14:07:46

On Wed, Nov 2, 2011 at 6:20 AM, Andrew Sutton <asutton.list_at_[hidden]> wrote:
>> 17.6.3.1? It's in 20.1.1 [lib.equalitycomparable] in C++03 and in 20.2.1
>> [utility.arg.requirements] in N3225. In C++03, the preceding text states:
>>
>> In Table 28, T is a type to be supplied by a C + + program instantiating a
>> template, a, b and c are values of type T.
>
> Hmm.. the n3290 seems to place them in 17. I see the wording that
> establishes the types now.
>
>> It makes sense, too; the table describes what it means for T to be
>> EqualityComparable. What would be EqualityComparable if a, b and c were
>> arbitrary?
>
> It should not be defined for arbitrary types. I've never argued that
> it should -- quite the opposite, in fact. What I've said is that the
> definition generalizes to a well defined subset of types.

I don't understand at all the benefits of defining EqualityComparable
formally in this case. What's wrong with providing an "as if"
specification of the algorithm, that is, show one example of its
implementation and require that alternative implementations are
equivalent? As long as that works with a separately defined
EqualityComparable entities, there is no need to couple the algorithm
with that definition.

Practically speaking, the possibility of abuse the other approach
attempts to protect against isn't a big deal, as long as people know
what works and what doesn't. What C++ feature isn't prone to abuse
anyway?

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode