Re: [boost] Boost.Algorithm design question

Subject: Re: [boost] Boost.Algorithm design question
From: Andrew Sutton (asutton.list_at_[hidden])
Date: 2011-11-01 14:44:41

>> It should not. Equality should mean equality. I don't see why this
>> should be so distasteful.
>
> First, unnecessarily requiring both sides to be of the same type causes
> problems with (for instance)
>
> signed char c1 = -1;
> unsigned char c2 = 0xFF;
>
> where c1 != c2, but they compare equal if either is converted to the type of
> the other. So this requirement leads to much extra complexity with
> common_type and so on.

But I'm not requiring both sides to be the same -- only related.
Also, this behavior is well defined and preserves the semantics of
equality. The common type of c1 and c2 is int -- it doesn't have (and
often isn't) one type or the other. int(-1) and int(255) are certainly
not equal.

Admittedly, you run into overflow issues with large enough integer
types, but c'est la vie. There are always implementation limits that
confound our best efforts to formulate accurate and meaningful
semantics.

> "test" == std::string( "test" ) == "test"
>
> but "test" may well not compare equal to "test".

Do you mean to say that the character pointed to by the first "test"
may not be the same as the character pointed to by the second? So:

"test" == "test"

might be false? That could be the case, but that's an issue with the
language's resolution of an operator for ==. Comparing pointers is not
the same as comparing strings. If the type of "test" was something
other than "const char*", say, constant_string, you could expect
different behavior.

> Third, because of the preceding two points, std::find does not, in practice,
> require same type or equivalence.

But it does, in practice, require equality comparison, which I am
suggesting should have a more precise definition.

> This leads people to use it with types of the form
>
> struct X
> {
>   int key_;
>   ... value_;
>
>   bool operator==( int key ) const { return key_ == key; }
> };
>
> Now... this is where you legitimately may claim that these people are wrong.

Generally yes, but I think I see how to generalize the relationship
between X and int that would satisfy the semantics of an equivalence
relation. Actually, I think I see how to do this for all types using
this comparison. I'll have to think on this.