> Hmm, but if I do this (in a unicode build):
>
> ATL::CString str(_T("T"));
> ATL::CStringA astr;
> astr = str;
>
> then astr will contain an ascii string, converted and all.
> Why isn't this character conversion? For the record, I got this from
> someone on the WTL list.I was talking about CString, not CStringA. CStringA and CStringW are new VC7 goodies, and using them for character conversion is possible, but anyway 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. 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.) > Anyway, wrt to > std::string: frankly, I think it sucks for unicode applications. There > is no build-in support for conversions and std::wstring isn't > available on every platform. On windows one could use > std::basic_string<TCHAR> but then all the changes like you have in the > header file you included in another message are needed; quite frankly, > that's a PITA. As long as a program is tied to windows (like any > ATL/WTL program is), I still think CString is a better choice than > std::string. > Time may prove me wrong, we'll see :) 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. ------------- Ehsan Akhgari Farda Technology (http://www.farda-tech.com/) List Owner: [EMAIL PROTECTED] [ Email: [EMAIL PROTECTED] ] [ WWW: http://www.beginthread.com/Ehsan ] Wishing that I could turn back time, so we could join our souls.
