[Qt-creator] Is MSVC on Windows supported?

[Coda Highland]

On Wed, Sep 5, 2012 at 8:42 AM, Coda Highland <chighland at gmail.com> wrote:
> On Wed, Sep 5, 2012 at 7:35 AM,  <kai.koehne at nokia.com> wrote:
>>> -----Original Message-----
>>> From: qt-creator-bounces+kai.koehne=nokia.com at qt-project.org [mailto:qt-
>>> creator-bounces+kai.koehne=nokia.com at qt-project.org] On Behalf Of ext
>>> Coda Highland
>>> Sent: Wednesday, September 05, 2012 4:19 PM
>>> To: Bornemann Joerg (Nokia-MP/Berlin)
>>> Cc: qt-creator at qt-project.org
>>> Subject: Re: [Qt-creator] Is MSVC on Windows supported?
>>>
>>> On Wed, Sep 5, 2012 at 6:11 AM, Joerg Bornemann
>>> <joerg.bornemann at nokia.com> wrote:
>>> > On 05/09/2012 13:58, ext Christian Kandeler wrote:
>>> >
>>> >> I don't understand the logic of this last sentence. People who use Qt
>>> >> won't use C++11?
>>> >
>>> > This implication was not intended.
>>> > Let there be program P, with P entirely based on Qt. Let F_P be the
>>> > set of C++ features P uses, F_MS be the set of C++ feature MSVC
>>> > supports and F_GW the set of C++ features MinGW supports.
>>> > Proposition: F_P = F_P \cap F_GW \cap F_MS \Rightarrow there's no
>>> > reason to build P using MinGW on Windows.
>>> >
>>>
>>> Who cares about C++ features? gcc 4.7 is a better compiler than MSVC2010,
>>> so unless Microsoft has gotten off their collective behinds with 2012 it's likely
>>> that gcc 4.7 is going to be a better compiler than that, too. The problem is with
>>> MinGW's standard libraries, not with the compiler.
>>
>> Define 'better' . I'm right now having the joy to more or less continuously compile Qt 5 with different MinGW variants, and it's really, really, dog slow.
>>
>> (MSVC is slow too, compared to gcc on Linux. But MinGW gcc takes slowness really to the next level...)
>>
>> Kai
>>
>> who is aware that this is now pretty off topic ...
>>
>>> /s/ Adam
>>> _______________________________________________
>>> Qt-creator mailing list
>>> Qt-creator at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/qt-creator
>
> MinGW is definitely a SLOWER compiler than MSVC, but MinGW gcc 4.7's
> optimizer is a lot smarter than MSVC's. (It optimizes a few cases
> better than icc, too, but icc does a few other things better than
> gcc.) Its libraries are where the problem really is, since the MinGW
> libraries haven't seen a whole lot of maintenance but the compiler has
> benefited from gcc's cross-platform development.
>
> It's a big change from before gcc 4.5. The stable version of MinGW was
> pretty bad before then, but 4.5, 4.6, and then 4.7 each saw major
> improvements.
>
> I wish I could find the study I was reading a month or so ago doing
> comparisons of most of the current C++ compilers for Windows; it was
> comparing MSVC, gcc, icc, Digital Mars, and a couple others, and it
> was incredibly detailed about the assembly language breakdown of what
> the compilers were doing, but my browser history doesn't seem to go
> back that far.
>
> /s/ Adam

I found it, and it was actually two PDFs:

http://www.agner.org/optimize/optimizing_cpp.pdf
http://dl.fefe.de/optimizer-isec.pdf

Of note, as of the time these articles were written, only gcc
performed tail-call optimization and C++ devirtualization, and gcc
auto-vectorized where MSVC wouldn't.

I recognize that MSVC has come a long way since then -- MSVC2010
picked up TCO (though gcc does it for more cases), but actually
produces LESS efficient code when it tries to devirtualize function
calls. MSVC2012 fixed the devirtualization problem and added
auto-vectorization, so I can definitely see that Microsoft HAS indeed
gotten off of their butts with regards to their compiler, but given
the history of the two compilers I don't see it being appropriate to
say that MSVC2012 is strictly better than gcc4.7.

Now, if your job consists of doing zillions of mind-numbing test
builds, I can see why you'd rather be using MSVC2012, because it DOES
compile code FASTER. But I don't consider compilation speed to be
important in judging which compiler is better than the other -- the
output they produce is far more relevant.

/s/ Adam