Re: [boost] Boost.Algorithm design question

Subject: Re: [boost] Boost.Algorithm design question
From: Andrew Sutton (asutton.list_at_[hidden])
Date: 2011-11-02 09:20:00

> 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 look at the problem like this: if you don't assign types, then the
question is, for which set of types of a and b can the expression a ==
b define an equivalence relation? I know that the behavior is correct
for char and int or string and const char*. Why? What's special about
those types that make them behave as if I was comparing objects of a
single type?