Invariant vs. Ordinal, the third

by Michael S. Kaplan, published on 2006/05/24 06:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/05/24/605599.aspx

Mike Sheldon is one of the smartest guys I know.

You may have seen him on Channel 9 talking about Windows Shell Architecture with fellow architect Chris Guzak.

And at least two people divined that he was the 'Mike' I credited in this post for his help with sublassing, Shell team style.

He has done a lot of other cool stuff too, but one of the very interesting jobs he has as an Architect on Shell team is in balancing the need for correct functionality with the need for backward compatible behavior.

He has been one of the people to work on when and how best to integrate some of the feedback that has come up before in this blog (though I have to admit that those blog posts were inspired by conversations at least as often as it actually inspired them!).

Yesterday, he sent some mail asking about how to handle a particular string comparison situation. Working through the scenario, in the end it boiled down to choosing between two different options:

CompareStringOrdinal with the bIgnoreCase flag set to TRUE, or
CompareString with LOCALE_INVARIANT and the NORM_IGNORECASE flag

Some will recognize this as the situation that has come up here before in posts such as Comparison confusion: INVARIANT vs. ORDINAL and Invariant and Ordinal Redux.

Of course a lot has been learned since then, including the different nature of testing for equality versus ordering. And it made sense to really cover the differences between these two very different methods to decide the best one to use.

Here are the basic differences, summarized:

CompareStringOrdinal is much faster;
Some strings will have no weight according to CompareString, but everything has weight according to CompareStringOrdinal;
CompareString with NORM_IGNORECASE will treat as equal many code points that would not necessarily be intuitive to treat that way such as "ʏ", "Y", and "y", as discussed here;
In most cases, equality results will be more intuitive using with CompareStringOrdinal while sorting results will be more intuitve with CompareString.

Of course this does lead to the mildly ironic situation where you do not call the function named CompareStringOrdinal when you want to figure out the order of things. But I have talked about the name weirdness before so I won't bore anyone by talking about it again. :-)

Now armed with this knowedge, Mike is able to make sure the Shell is doing the right thing in many of its own string comparison needs!

This post brought to you by "ʏ" (U+028f, a.k.a. LATIN LETTER SMALL CAPITAL Y)

Michael S. Kaplan on 24 May 2006 10:16 AM:

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

referenced by

2007/10/12 That function is always faster! (well, except for that one case when it can actually be slower...)

2007/05/31 Something .NET does less intuitively than they ought

2006/08/16 Something .NET does more intuitively than Windows

go to newer or older post, or back to index or month or day