Compare without regard to case

[Richard Herring]

#include <cctype> // for tolower()
#include <cassert>

// returns < 0 if s1 < s2, > 0 if s1 > s2 or 0 if the strings
// are equal (without regard to case)
// ie. behaves like strcmp()

int stricmp(const char *s1, const char *s2)
{
while (*s1 && *s2)
{
if (tolower(*s1++) != tolower(*s2++))
{
return (int) tolower(*s1) - (int) tolower(*s2);
}
}

return (*s1 ? 1 : (*s2 ? -1 : 0));
}

int stricmp(std::string s1, std::string s2)
{
return stricmp(s1.c_str(), s2.c_str());
}

Won't behave correctly if either of the strings contains embedded '\0',
as comparison will stop at the first one.

 

[Andre Heinen]

char k = 'A';

unsigned char& uk = *reinterpret_cast<unsigned char*>(&k);

Do we have any guarantee that the bit representations are the
same for signed char and unsigned char? What about machines that
use one's complement or BCD?

 

[Mark Wright]

One joyful day (Thu, 16 Sep 2004 09:58:35 +1000 to be precise), "David
Fisher" <[email protected]> decided that the Usenet community would
benefit from this remarkable comment:

int stricmp(std::string s1, std::string s2)
{
return stricmp(s1.c_str(), s2.c_str());
}

After many years of doing this myself, this kind of thing now bugs me
intensely. What, you may ask?

Well, I once had a performance issue with a core piece of code I'd
written and ran it through a profiler. To my surprise, way at the top of
the list was the copy constructor for std::string! Replacing this:

int stricmp(std::string s1, std::string s2)

with this:

int stricmp(const std::string &s1, const std::string &s2)

is a whole lot more efficient.

Mark Wright
- (e-mail address removed)

================Today's Thought====================
"In places where books are burned, one day,
people will be burned" - Heinrich Heine, Germany -
100 years later, Hitler proved him right
===================================================

 

[JKop]

Andre Heinen posted:

Do we have any guarantee that the bit representations are the
same for signed char and unsigned char? What about machines that
use one's complement or BCD?

Yes, you're guaranteed that all positive numbers will have the same bit
representation for both signed and unsigned and that's for all the integer
types. (Taking this from my memory, it's there in the standard...
somewhere...).


-JKop

 

[Andre Heinen]

Yes, you're guaranteed that all positive numbers will have the same bit
representation for both signed and unsigned and that's for all the integer
types. (Taking this from my memory, it's there in the standard...
somewhere...).

Actually I was worrying about negative numbers (e.g. ASCII
between 128 and 255).

 

[Julie]

Julie posted:


Actually, it's for filenames.

kernel32.dll

and

Kernel32.DLL

and

KerNel32.DlL

are the same file!

-JKop

Then you are better suited using an equality test. I'd suggest reposting under
that premise, and you should get better responses (reason being:
compare/collation includes a lot of unnecessary features that aren't needed for
a simple equality test, and those features aren't simple to resolve in a
platform independent/locale independent way).

 

[Rich Grise]

Won't behave correctly if either of the strings contains embedded '\0',
as comparison will stop at the first one.

When they made the enhancements to C to create C++, did they redefine
the string terminator? I haven't finished the book yet, but I'd have
thought something like that would be kind of important to highlight.

Thanks,
Rich

 

[David Fisher]

When they made the enhancements to C to create C++, did they redefine
the string terminator? I haven't finished the book yet, but I'd have
thought something like that would be kind of important to highlight.

He was pointing out that a std::string can contain an embedded null
character, and is defined by the string length rather than requiring a
terminator ... the value returned by c_str() has a '\0' at the end, but if
there is an earlier '\0' then the string will seem shorter.

I guess this is important in a library function like stricmp() ... maybe
overkill for other situations ...

David Fisher
Sydney, Australia

 

[Richard Herring]

In message <[email protected]>, David Fisher
<[email protected]> writes

[...]

Won't behave correctly if either of the strings contains embedded '\0',
as comparison will stop at the first one.

When they made the enhancements to C to create C++, did they redefine
the string terminator? I haven't finished the book yet, but I'd have
thought something like that would be kind of important to highlight.

std::string doesn't require a terminator, as it keeps an explicit record
of the length. The only parts of it that have any concept of terminator
are those functions which take a single pointer as argument and expect a
C-style null-terminated char array.

String constants still contain a terminating null, and the str...
functions are unchanged from C.