Qt "When" questions??

[fsmoke]

I have several questions:

When will be the Qt Add-In plugin for microsoft visual studio studio 2012?

When Qt by default will use built-in wchar_t? May be in Qt5??

[ChrisW67]

When will be the Qt Add-In plugin for microsoft visual studio studio 2012?

When somebody writes it or updates the existing plugin for whatever arbitrary changes Microsoft have seen fit to introduce.

When Qt by default will use built-in wchar_t? May be in Qt5??

I very much doubt it ever will. The size (anything from 8 to 32 bits) and meaning of wchar_t is variable between compilers and Qt needs to be cross-platform, which is at least part of the reasoning for a QString that is consistent. As the Unicode standard 4.0 Section 5.2 says, "... programs that need to be portable across any C or C++ compiler should not use wchar_t for storing Unicode text. The wchar_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers." You can, of course , convert a QString to/from an array of wchar_t... whatever size that is on your machine.

[fsmoke]

When somebody writes it or updates the existing plugin for whatever arbitrary changes Microsoft have seen fit to introduce.

I very much doubt it ever will. The size (anything from 8 to 32 bits) and meaning of wchar_t is variable between compilers and Qt needs to be cross-platform, which is at least part of the reasoning for a QString that is consistent. As the Unicode standard 4.0 Section 5.2 says, "... programs that need to be portable across any C or C++ compiler should not use wchar_t for storing Unicode text. The wchar_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers." You can, of course , convert a QString to/from an array of wchar_t... whatever size that is on your machine.

As far as i know QString uses unsigned short inside and it has no dependences of wchar_t. All in Qt builded on QString's - I see no reason why wchar_t is not built-in; Besides no differences(at least in the Windows) because built-in wchar_t is 2 bytes and non-builtin wchar_t is 2 bytes.

All normal libraries(except Qt) under c++ use built-in wchar_t - and constantly I spend a lot of time to reconfigure and rebuild them with /Zc:wchar_t-, because by default they incompatible with Qt.

Yesterday I rebuild Qt with no /Zc:wchar_t- flag.

I want to ask - would it not be any problems? Am I correct in my thinking about Qt strings? (I want some proofs if I am wrong )

[wysota]

I see no reason why wchar_t is not built-in

Built-in into what?

Besides no differences(at least in the Windows)

"at least in Windows". Sadly, I'm not using Windows right now and I really like Qt...

All normal libraries(except Qt) under c++ use built-in wchar_t

What exactly prevents you from using it?

I want to ask - would it not be any problems? Am I correct in my thinking about Qt strings? (I want some proofs if I am wrong )

If Qt doesn't use it, Qt doesn't care. You can use it if you want, but don't blame Qt for any incompatibilities you might encounter.

[fsmoke]

Built-in into what?

What exactly prevents you from using it?

It is option of msvc++ compiler - called "Treat WChar_t As Built in Type" - so if it turn off(As in Qt) - wchar_t becomes just a define

In other normal libraries it turned ON - but in Qt it turned OFF. So when I link another libraries with Qt Applications - linker writes errors.

Try to link boost with Qt Application for example - and you got link errors!!!!!

If Qt doesn't use it, Qt doesn't care. You can use it if you want, but don't blame Qt for any incompatibilities you might encounter.

No I will blamed Qt - because it's not my whim - Qt forces me to rebuild self without /Zc:wchar_t- flag, or rebuild all other libraries to be compatible.

This is what I am talking about:
http://stackoverflow.com/questions/4...w-up-the-world

[wysota]

It is option of msvc++ compiler - called "Treat WChar_t As Built in Type" - so if it turn off(As in Qt) - wchar_t becomes just a define

So it's not compiler agnostic and hence is unportable...

In other normal libraries it turned ON - but in Qt it turned OFF. So when I link another libraries with Qt Applications - linker writes errors.

I have used some libraries on Windows and never encountered that error. Thus we can probably assume some libraries have it on, some have it off and others don't care.

Try to link boost with Qt Application for example - and you got link errors!!!!!

Many people successfully use Boost with Qt so I don't think it's a common problem. Sometimes you just need to rebuild something (be it Qt or any other lib) because the default options are not satisfactory. Is it that much of a problem?

[fsmoke]

So it's not compiler agnostic and hence is unportable...

no - you don't want understand me at all . Qt ported on many platforms - and every platform have own specifics, but no differences between wchar_t and unsigned short - on WINDOWS. My question is: Why Qt not using built-in wchar_t on windows and use frustrated define wchar_t to unsigned short - on windows sizeof unsigned short and built-in wchar_t are both 2 bytes. No reason using this compiler flag on windows - it's no differences. And this question is not question of portability at all. It's no need to change source code at all.

I have used some libraries on Windows and never encountered that error. Thus we can probably assume some libraries have it on, some have it off and others don't care.

I can't understand - I already wrote to you in previous post: try to use boost file system, for example, with Qt app - you got link errors(about different wchar_t types). Besides I post to you link to stackoverflow.com- proof that problem exists.

Many people successfully use Boost with Qt so I don't think it's a common problem. Sometimes you just need to rebuild something (be it Qt or any other lib) because the default options are not satisfactory. Is it that much of a problem?

When project consists of many libraries - and some of them periodically updated - so when you download new version you must change configs, makefiles and so on (and then rebuild) to link it with Qt application. So YES it's problem sometimes!
Problem at empty place!!!

Besides I didn't see any library (except Qt) which uses this flag.

PS
Your status is Master of Zen - Why I tell you trivial things. If you think I am new in Qt or c++ - you are wrong - I have about 12 years expirience in cpp. I am senior and team lead - just for information.

[Dainius]

For me it looks like someone in Qt team (senior enough) decided that for compatibility reasons wchar_t always should be unsigned char, most other libs think that compiler writers (and developers) are smart enough to know what is better for them.

As for compatibility with other libraries, it's usually not a problem until you use any method with wchar_t. In a past I used boos with qt, but in these days is much harder, because now wchar_t is much more popular then it was 5 years ago.
Anyway it would really interesting to read a research paper about compatibility problems with native wchar_t in different compilers on different platforms (I hope there is such, as else it would be just wild guess and give people many difficult hours of trying solve what isn't broken).

no - you don't want understand me at all . Qt ported on many platforms - and every platform have own specifics, but no differences between wchar_t and unsigned short - on WINDOWS. My question is: Why Qt not using built-in wchar_t on windows and use frustrated define wchar_t to unsigned short - on windows sizeof unsigned short and built-in wchar_t are both 2 bytes. No reason using this compiler flag on windows - it's no differences. And this question is not question of portability at all. It's no need to change source code at all.



I can't understand - I already wrote to you in previous post: try to use boost file system, for example, with Qt app - you got link errors(about different wchar_t types). Besides I post to you link to stackoverflow.com- proof that problem exists.



When project consists of many libraries - and some of them periodically updated - so when you download new version you must change configs, makefiles and so on (and then rebuild) to link it with Qt application. So YES it's problem sometimes!
Problem at empty place!!!

Besides I didn't see any library (except Qt) which uses this flag.

PS
Your status is Master of Zen - Why I tell you trivial things. If you think I am new in Qt or c++ - you are wrong - I have about 12 years expirience in cpp. I am senior and team lead - just for information.

[d_stranz]

In Qt5 on MSVC, the "treat wchar_t as a built-in type" flag is now set to YES. In all previous versions of Qt, it was set to NO. This is true for both the binary installer versions of Qt5 as well as in the qmake.conf configuration files for the various MSVC versions.

For those who seem unaware of the difference:

When "treat wchar_t as a built-in type" is set to YES, this means that the compiler treats it as a full-fledged C++ type, just like int, double, and so forth. It is irrelevant whether it is the same size as an unsigned short, it is a different type than unsigned short under that case. It's a "wchar_t" type.

When the flag is set to "No", then the compiler treats is as though it is an unsigned short because it is either typedef-ed or #define-d to be one.

So if you try to link binary code files where the "Yes" and "No" flags are different, and those binary code files use wchar_t, then you will get undefined symbol errors, because the linker is looking for something different than what has been built into each of the binaries. A wchar_t type is not the same as an unsigned short type.

This change in flag is a serious pain in the butt. It means that you either have to 1) rebuild everything that your apps depend on so they have the same flag setting, or 2) rebuild Qt from source after reconfiguring to use the old-style flag. I chose to rebuild Qt, because I am not willing to change config files for everything else just because the Qt developers chose to do something stupid without telling anyone.

I use boost strings all the time, because I must interface my Qt apps with non-Qt libraries that use std::wstring (and wchar_t). Boost strings are defined as C++ templates, so whatever wchar_t is defined as when you compile any piece of code that uses them, that's what you get. If you try to mix code that uses boost strings that has been compiled using opposite definitions of wchar_t, that's when you get link errors. It isn't boost that is causing the problems, it's Visual C++.

Ironically, the Qt plugin for MSVC creates new projects with the flag set to "No", which means if you use the plugin to create a new project and you use wchar_t, you get link errors right out of the box. Qt's right hand doesn't know what its left hand is doing.

[ChrisW67]

This thread started out as a complaint that "Treat WChar_t As Built in Type" was off by default in Qt and has worked around to being a complaint that setting "Treat WChar_t As Built in Type" on by default is a "a serious pain in the butt." All we need now is to invoke Godwin's Law and the thread will be complete

For the record, I don't do enough mixed Windows programming to care either way.