Hi,
Does it make sense to have a std::map<char*,blah>? It seems to me that string literals' pointers would be compared instead of the strings themselves, as would normally happen for char* str1 == char* str2.
However, in my experience, std::map<char*,blah> constructions DO seem to work properly--so I'm assuming that the STL is doing a string equality test instead?
Thanks,
Ian
That seems unlikely. Best use proper strings:Originally Posted by Geometrian
std::map<std::wstring, blah>
To create a map for C-strings you must include the third parameter in the map declaration. This is the function for sorting these C-strings. See this link: map<Key, Data, Compare>
Jim
Don't use C-style strings unless you have a good reason, please. No need to feed that into the fire unless we are sure it's needed.
IOW, don't mention C-style stuff unless we are certain the OP needs it.
No it mostly wont work, except in a few cases where you're lulled into a false sense of security.
If the linker sees two strings like "hello" assigned to a pointer in one place and then "hello" asigned to a pointer in another, then it may make both point of them at the same string in your executable to save space. So the only reason it appears to work is that the two compare equal since the pointers are equal.
Unless you use std::strings or similar, then what you're doing will break the moment you use it for anything but a toy example. Try inserting into the map using a hard coded string as the key, and then getting a string from the user and looking that up. It will not find it.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
Ah thanks; I was wondering why it was working. I've changed everything over to use std::string now.
Thanks again, everyone.
Please make that std::wstring at the very least. It's time to dump ANSI.
Hopefully the next standard should clear some of this mess up.
Why wstring? I've found them work awfully for internationalization, and it still doesn't help in most cases: utf8/utf16 mixups in different OSs make it do completely different things from what I've seen. So personally, I prefer to use utf8 strings if internationalization is needed.
At least it allows you to work internationally natively without extra libraries. Or at least hopefully. It works so-so on Windows.
And the fact that std::string would probably not be very good for UTF-8.
I would prefer real unicode types for utf-8 that works >_<So personally, I prefer to use utf8 strings if internationalization is needed.
But there is also one other thing: IMHO, ANSI should never be used. And the fact that it is typically used everywhere in your typical C++ code disgusts me. Other languages have long since only worked with unicode. So that's an area where C++ lags behind.
Anyway, there is little to loose on using wstring, so one might as well.
Whilst you're entitled to your opinion, you don't even know what kind of strings he's using this for. It may be strings of digits, morse code, or numberplates etc, for example.
I happily use std::wstring and CComBSTR etc on a daily basis, but ASCII, UTF8, and std::string will always have their place. However, talking in such absolutes is only going to get you rightly corrected. Never say "never", and remember that you don't have a personal stake in his project.
Last edited by iMalc; 02-21-2011 at 12:42 AM.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
Come now, it's a plea, not a demand. But correct me if I'm wrong, I don't think std::string works very well with utf-8.
Strong words! Why do you care so deeply about having an extended character set? I've hardly ever even thought about it.
Because it causes problems! Alla non-english characters cannot be represented by ANSI. It would rely on non-standard extended character set which tends to be different for each language of Windows. Among other things.
Then the day comes when you have to use special characters. But they won't work properly with ANSI. So you have to redo a lot of your code to make it work.
All programming languages nowadays use Unicode by default. It's a mystery why it's still standard practice to teach ANSI in C++.
I'm not sure if an std::string can or can't represent it. I'm quite sure a char is defined to be at LEAST 8 bits since C++ - am I right? Now I'm not sure if all values are always considered allowed, but if so it means a UTF-8 string can always be represented in an std::string.
But then again, you know the standard WAY better than I do, as I always got bored trying to read it so I never actually finished it. So you tell me if it can or can't ;-).
But an std::wstring just doesn't work nicely in Linux, I think. I don't even remember what the problems were, but as Linux works with UTF-8 usually and std::string's work perfectly for UTF-8 in Linux at least, all input and output functions worked great.
Since std::string works with char, it means you cannot iterate a utf-8 string since it will always move one byte at a time. Furthermore, any string operations on string will be unlikely to work since they assume that every char is one byte.
Wide strings OTOH can represent far more characters since they're all 2 bytes per default.
Neither are perfect solutions, but at this time, I do believe that wstrings are a better alternative.
