[Qt-interest] Question about "wchar_t" support on Windows

Bo Thorsen bo at fioniasoftware.dk
Thu Jan 20 17:00:54 CET 2011


Den 20-01-2011 16:51, Yves Bailly skrev:
> Keith Rusler a écrit :
>> What makes you think it doesn't? If it doesn't, why should it?
>>
>> On 20 January 2011 09:38, Yves Bailly<yves.bailly at sescoi.fr
>> <mailto:yves.bailly at sescoi.fr>>  wrote:
>>      Keith Rusler a écrit :
>>       >  use QString::toWideChar() or QString::toStdWString().c_str()?
>>
>>      I'm aware of these, however it doesn't answer my question:
>>      why would Qt need to *not* consider "wchar_t" as a native type?
> What makes me think it doesn't is the presence of this -Zc:wchar_t- option
> on the compiler command line.
>
> About "why should it",
> 1- maybe because it seemed to me it *is* a native type according to
>     the C++ standard, unless I'm not reading it correctly;
> 2- again, why shouldn't it?
>
> I'm just trying to understand why this option is given to the compiler.

After spending the last months coding server side C++ with Visual 
Studio, it's a great relief to be back with Qt and the QStrings. Outside 
the Qt code, strings are a fragmented mess that it's impossible to work 
with. And bastards like CString doesn't make it easier.

wchar_t is not a native type. It's a typedef to something else. With 
QChar, you know what you get.

If C++ had done strings in a way that makes more sense, maybe QString 
and QChar wouldn't exist.

I can't give you a single good reason, but when working with strings, 
the Qt classes just makes you life so much simpler. Again :)

Bo Thorsen,
Fionia Software.

-- 

Expert Qt and C++ developer for hire
Contact me if you need expert Qt help
http://www.fioniasoftware.dk




More information about the Qt-interest-old mailing list