Operator Overoverloading

Studying part of a large complex middleware for a management web application, and wondering why this:
InitechString str1, str2;
...
if(!(str1 != str2))
{
    ...
}

occurred almost as often as this:
InitechString str1, str2;
...
if(str1 == str2)
{
    ...
}

I dug a little deeper and found...


// CASE-SENSITIVE COMPARISON
//
int InitechString::operator==(const InitechString& r) const
{
    return !strcmp(m_ptr, r.m_ptr);
}
// CASE-NONSESTIVE COMPARISON
//
int InitechString::operator!=(const InitechString& r) const
{
    return !!strcmp(m_ptr, r.m_ptr);
}

>>5
It does have a length and a bunch of other stuff. They're not using it here though. I don't think the Indian stereotype applies, the bulk of it was written in the early 90s.

>>17
You think the compiler is smart enough to do deep analysis like that? It's not quite as much as expecting it to replace bubblesort with quicksort, but not far either.

>>18-20
The same could be made for <, >, <=, and >=, but then again it's those special cases that people would be bitching about if they didn't let you define all of them separately. (However, shorthand notation for defaulting != to the negation of ==, >= to > || ==, etc. would be welcomed.)

It's funny how no one complains about these features in Perl 6, which lets you change the precedence of overloaded operators. I can manage understanding code that uses nonstandard operator overloading and just barely remember the majority of the template system, but I don't think overloaded operators with varying precedence are within my ability to parse correctly.