0

I am compiling my Qt project in Qt Creator using the MSVC2017 32bit compiler. It compiles and runs error-free, but some functionalities don't work anymore. (I am comparing it with the MinGW compiler.)

As the project is quite big and I do not get any error messages (and the debugger is not working), it is hard to narrow down the issue. So I wanted to ask generally: What are possible problems that arise when switching to MSVC in Qt Creator? (After solving all configuration issues etc.) Do some Qt classes stop working? Do some signals stop getting emitted? What problems did you encounter before and how did you solve them?

Deleting build file, cleaning, running qmake, rebuilding doesn't change anything.

Mariam
  • 342
  • 3
  • 18

1 Answers1

0

There are no problems related to Qt Creator, because Qt Creator is an IDE and has approximately nil to do with whether the build products work or not. MSVC 2017 is a supported Qt platform, so on that front you should be fine. You might wish to ask, then, whether MSVC 2017 adds any problems compared to mingw. In my experience, it used to be the other way around: usually mingw would add problems, related to its perpetually lagging-in-completeness platform headers, compared to MSVC. These days, the two should be on par, I'd hope.

The build is done in two stages: qmake (or cmake) followed by make. Qt Creator merely runs these two, with the environment set up as-if vcvars was invoked first. You'll get identical builds from the command line by invoking vcvarsall, qmake (or cmake), then nmake (or jom or ninja, depending on circumstances).

"some functionalities don't work anymore" isn't really helpful: Please amend the question to explain exactly what doesn't work. Ideally, show some test cases that reproduce the issue. It's quite possible that you had some undefined behavior that didn't rear its ugly head with the gnu compiler, but does with MSVC. That's not uncommon in large projects if they weren't developed with good test coverage and static analysis.

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313
  • yep, I had some mistake that wasn't discovered by the old compiler! – Mariam Aug 30 '18 at 14:41
  • An aside: it's not the compiler's job to find mistakes that the standard doesn't require it to find. That's what tests and a disciplined approach to software engineering is for: the best way of avoiding mistakes is by design, i.e. constructing the software such that in spite of human fallibility, the mistakes are unlikely or impossible. – Kuba hasn't forgotten Monica Aug 30 '18 at 14:43
  • yes, makes sense. But you got to start somewhere and of course in the beginning it is not perfect.. – Mariam Aug 30 '18 at 14:51
  • 1
    Of course! I'm just pointing out that one approach to finding bugs is design that makes (some) bugs impossible -- it is an approach oft forgotten. Modern C++ enables writing code where outside of a core set of low-level classes, most bugs won't compile. That's a significant leap over what was possible 20 years ago, for example. – Kuba hasn't forgotten Monica Aug 30 '18 at 15:52