String comparison of arguments

#1 What do you have against the built in string compare functions?

#2 If I was only comparing apples and oranges, I'd use the torque script string compare functions. The code that I'm working on in is more complex than my simple example.

Still, your don't-do-it-that-way comment is valid - this works:

Con::printf("Is %s equal to APPLE? %d", argv[2], strcmp(argv[2],"APPLE"));

- using the strcmp method defined in . I tried , which I though was equivalent, but that caused the program to die a horrible, painful death. But now I'm good to go.

Thanks for the kick in the right direction.

#3 John,
you're bumping into a fundamental aspect of C: you can't compare strings using the "==" operator.

basic strings in C/C++ are implemented as pointers to arrays of chars.
the "==" operator is comparing the pointers, not what the pointers point to.

the way to compare strings in C is indeed using the strcmp() function,
although in Torque, you should use the "d" flavour: dStrcmp().
also, i would recommend looking up the definition of strcmp().
it returns 0 if the strings are equal, and non-zero if they're not.
you might also be interested in dStricmp(), which is the case-insensitive version.

#4 Thanks Orion

You're right, of course. I've got Java on the brain and without an equals method on a string object, I apparently will try just about anything. Surprise, surprise - the memory address of the two arrays are not the same. I should know better...

I didn't know that strcmp returns 0 for true - you've saved me from pulling out what little hair I have left. I'm assuming that this is because it's not a test of equality but a comparison: -integers are less than, 0 is equal, positive integers are greater than. Thanks.

Just curious as to what the "d" flavour is - Torque specific or another gap in my C knowledge?

#5 Honestly i'm not sure what the "d" is for.
the functionality is usually* identical, just with a "d" in front.
i use it to just to be consistent.

* one significant function w/ a different signature for the "d" version is dSprintf: dSprintf is more or less equivelant to swprintf, in that it requires you to pass in the size of the buffer you're printing to. (always a good idea)

#6 That's a good enough explanation for me.

One thing I have found - there's no need to include additional headers when using the d versions. This makes my problem with whether to use or moot.

#7 When this code was originally written back in early 90s it wasn't as clear how portable the c-runtime was to future gaming consoles.

The "d" versions of the c-runtime library functions are just Torque wrappers that exist for the cases where a new platform doesn't fully support the stock c-runtime or when more optional versions exist. You see the same thing with "m" versions of math functions... mSin, mFabs, etc.

I suspect the "d" stands for Dynamix.