Re: Top 10 Worst C# Features

[Maciej Sobczak <see.my.homepage@gmail.com>]

> Do you mean that there are reasons to permit !(a == b) and a != b to
> have different values in some cases?

Why not? We are already talking about the language where a+b is not necessarily equal to b+a (hint: strings). ;-)

There is also an interesting area for objects that might be neither "equal" nor "different" (that is, where both operators might return false at the same time).
As an illustration, Apples and Oranges are neither equal nor different, even though they are all Fruits and might be modeled in a flat type system.

Of course, diverting from the usual laws is asking for trouble, but as I have already said - some programmers might be willing to get some added flexibility at the expense of higher verification effort. Definitely, one should not automatically assume that all C++ programmers are morons.

> I don't see why
> 
>   bool operator!=(const T &other) const noexcept
>   {
>     if (this.hash != other.hash)
>       return true;
>     return !this.long_slow_equality_test(other);
>   }
> 
> is any more or less efficient than
> 
>   bool operator==(const T &other) const noexcept
>   {
>     if (this.hash != other.hash)
>       return false;
>     return this.long_slow_equality_test(other);
>   }
> 
> but I may have missed the point you are trying to make.

No, but you have missed the point that I tried to address. Your example is OK with regard to performance, but for some reason you have still used *distinct* implementations of these operators, instead of calling one from another. And interestingly, your WCET is even worse than in my example, as it might need to execute two comparisons (fast and slow) instead of just the one which is asked for.

Of course, I don't claim that these are typical usage scenarios. Typically, these operators indeed should be based on common logic.

-- 
Maciej Sobczak * http://www.inspirel.com