Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Operator Overoverloading

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2013-02-22 6:56

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);
}

Name: Anonymous 2013-02-22 7:56

>>3
Third WTF is that they use their own string class, which is probably retarded. I mean, they don't compare lengths, right? Which means that they don't store lengths, which means that their appending operator does strlen, strlen, realloc, and then probably strcat instead of memcpy because they are retarded like that.

But at least they deliver ENTERPRISE application written in C++, so it's full of PERFORMANCE.

The worst part is that while your guys are probably Indians and therefore expected do shit like that, I'm working with a codebase which has a similarly retarded string implementation, and that was written by entirely white retards. I mean, there goes a possible heuristic for avoiding code like that.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List