I am investigating the handling of case-insensitivity in my application. So far I realized that there are two different cases:
- data is visualized to the user
- data is internally handled
For case 1 you should use the user's locale, always. This means that e.g. when sorting items in a list and you want this to happen case-insensitively, then you should use locale-aware case-insensitive string compare functions.
For case 2 it seems logical that you don't want to use the user's locale, since this can have undesirable effects if you have users using a different locale, but still using the same data set (e.g. if you are managing library software, you could use the book's name as key for your book instance in the database, and want to handle this case-insensitive (this is a simplification, I know)).
When using STL containers (like std::map) I noticed that it's much more efficient to put the key in uppercase and then perform the lookup on the uppercase'd search-value. This is more efficient than performing a case-insensitive compare while looping over the map. For std::unordered_map it's probably required to do such a trick.
However, I realized that this may have strange effects as well, and I am wondering how Windows (also using case-insensitive file names) handles these situations.
E.g. The German character ß (ringel-S) is written as SS when put in uppercase. This seems to imply that ß.txt and SS.txt should denote the same file, and so ßs.txt and sß.txt and sss.txt and SSS.txt should also denote the same file. But in my experiments this doesn't seem to be the case in Windows.
So my questions:
- Which C++ and/or Windows functions should be used to perform locale-independent case-insensitive string compares?
- Which C++ and/or Windows functions should be used to make a string case-less (e.g. put it in uppercase) so compares are then more efficient when performing a lookup in an std::map (or even making hashing possible when using an std::unordered_map)?
- Any other experience (or links to documents) regarding case-insensitive string handling for internal (i.e. non-visualization-related) data?