Compare results, why when both are equal the result is '0'?

• Question

• Im not sure if this is me keeping PHP methods in my head again, but this one to me seems to be a no-brainer that is completely out of synch with everything else I have been taught...

when comparing to strings, If I was to use an operator method:

string StringOne = "Jimmy";

string StringTwo = "Jimmy";

if (StringOne == StringTwo)

{

//do something here

}

this method provides a TRUE or FALSE answer, in its basic form that would be 1 - TRUE or 0 - FALSE,

but using the compare() function, you are returned a 0 value if the result is true!:

if (String.Compare(StringOne, StringTwo) == 0)

{

//do something here

}

To me that goes completely against the grain... if the result of the comparisson means that both are equal, this equates to a TRUE comparrison, therefore the result should be 1, not 0...

Am I completely missing the point here, or are TRUE/FALSE 1/0 used in completely different ways?

compare() as far as I can tell is a basic AND function if a AND b are equal the the result must be true...

Please can someone help me clear this up?

many thanks for any help,

Jimmy

Sunday, July 18, 2010 5:05 PM

• The Compare method was primarily designed for sorting purposes, but it works perfectly well for regular comparisons as well. It determines which of two strings comes first when sorted so just returning a bool wouldn't have worked. The method returns a negative value if the first string comes before the second, positive if the second comes before the first and that leaves zero for the case when they are equal.

It might not be the most intuitive return values since the value of the int is not really interesting, just whether it's above, below or exactly zero. Still it is an easy way to a case where you have three different return possibilities.

Anyway, the real reason for the methods behavior is probably historical. It is the .NET equivalent of the old C method strcmp, and it behaves exactly like strcmp. strcmp survived to the C++ standard library, and C++ is basically the predecessor for C#.

/Simon

• Proposed as answer by Monday, July 19, 2010 4:54 AM
• Marked as answer by Monday, July 19, 2010 9:48 AM
Sunday, July 18, 2010 7:53 PM

All replies

• A comparison has a tri-state result as the usual comparison is in a sorting routine.  .NET booleans do not cast directly to integers as C and legacy VB booleans did.
• Proposed as answer by Monday, July 19, 2010 4:54 AM
Sunday, July 18, 2010 7:37 PM
• The Compare method was primarily designed for sorting purposes, but it works perfectly well for regular comparisons as well. It determines which of two strings comes first when sorted so just returning a bool wouldn't have worked. The method returns a negative value if the first string comes before the second, positive if the second comes before the first and that leaves zero for the case when they are equal.

It might not be the most intuitive return values since the value of the int is not really interesting, just whether it's above, below or exactly zero. Still it is an easy way to a case where you have three different return possibilities.

Anyway, the real reason for the methods behavior is probably historical. It is the .NET equivalent of the old C method strcmp, and it behaves exactly like strcmp. strcmp survived to the C++ standard library, and C++ is basically the predecessor for C#.

/Simon

• Proposed as answer by Monday, July 19, 2010 4:54 AM
• Marked as answer by Monday, July 19, 2010 9:48 AM
Sunday, July 18, 2010 7:53 PM
• Okay I can see that,

but why keep it? I mean, if C# was supposed to be a 'brand new'  language and I quote many sources that all say 'C# is built to over come the problems that were inherant in C/C++, it just seems to me that this is a perfect example,  it could have been much easier with SortCompare, not String.Compare, as the first implies that methods described whereas the second implies a return result of true or false.

Oh well, I suppose I will have to look out for the quirks and C# 'weirds' to prevent myself creating bugggy code

Jimmy

Monday, July 19, 2010 9:46 AM
• This is a .Net thing, not a C# thing.

string.Compare() is a .Net method.

The reason that it works how it does is to make it compatible with the IComparable interface. This is extremely useful, since it means you can plug a string into any algorithm that expects an IComparable object. Very powerful.

Monday, July 19, 2010 10:36 AM
• Ok I can accept that there is a use for this function outside the scope of what I have learned already, I am just finding it difficult completley re-adjusting my thinking from PHP methods which I have used for quite sometime now, the first habit I had to break was the way in which I viewed varaibles, there interaction with functions/Objects etc, it just seems everrytime I get my head round one, another four huge differences turn up!

I will learn this language and I will migrate to C# lolz!

All the best

Jimmy

Monday, July 19, 2010 10:46 AM
• I understand your difficulties. There is indeed a big difference with how objects work in a statically type language compared to a dynamically typed. I have never worked in a dynamic language myself. I'm sure I would have a lot of difficulties switching to PHP.

The good thing is, when you've mastered C#, it's a really short step to VB and not that long to C++. So it's a good way to broaden your profile.

Good luck! Regards,

Simon

Monday, July 19, 2010 11:16 AM
• I don't understand the problem when switching from php.

In php, strcmp does exactly the same thing as in C.

http://php.net/manual/en/function.strcmp.php

Tuesday, July 20, 2010 1:12 AM