I was talking about CString, not CStringA. CStringA and CStringW are new VC7 goodies, and using them for character conversion is possible, but anyway
Ah yes, I always forget to mention that I'm working with ATL 7.
the ATL conversion macros will be more efficient for normal cases, because they allocate their memory from the stack, which is much faster than the heap allocation used by CStringA/CStringW.
That's true, but still, for conversions let's say in a tight loop (like when looping over all elements of a large xml document with msxml for example) I'm not really comfortable with using the stack for that. It's probably just a wrong gut feeling that I have, I'm always afraid that I'll run out of stack space one day.
If you choose CStringA/CStringW, just note that they're not available in VC6 (in case you would need to port your code to VC6.)
True. This is not an issue in my case, but it could be for some people.
I generally prefer std::basic_string for the code I need to port to other platforms besides Windows. This means that I use them mainly for the libraries (or other re-usable stuff) I write. In several cases, if I use such a library on Windows, I prefer std::basic_string for the Windows app as well to be compatible with the string types the library is using.
Yes that is absolutely true. STL is the most portable way at the moment; the point that I was trying to make is that I no longer think of std::string as the end and all of string classes. I've been thinking of starting to use Glib::ustring (http://gtkmm.sourceforge.net/gtkmm2/docs/reference/html/classGlib_1_1ustring.html, a utf-8 string class with a std::string interface) for my projects that may some day need cross-platformness but I have to investigate just how fast a utf-8 string can be. But as I mentioned before, I'm still new to the whole unicode/internationalization thing, so I may be wrong on this one too :)
cheers,
roel
