[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