4 ms·

MSVC: The Devourer of Const

43 points by ibobev 4y ago

zone411 4y ago
/permissive- is now the default.
- planede 4y ago
  Yep, also /permissive is super non-conforming. My favorite /permissive "feature": `false` is a null-pointer constant: https://godbolt.org/z/Mzjfba1en https://godbolt.org/z/Mzjfba1en
hoseja 4y ago
I hate the Miscrosoft Developer Community reporting so much, the bot replies and the outsourced dismissals are so infuriating.
- zone411 4y ago
  My experience (C++): - 3 bugs marked as "Our teams prioritize action on product issues with broad customer impact" and never fixed - 1 bug fixed - 1 bug merged with another bug and fixed
  - daemin 4y ago
    Really need to publicise issues in the tracker and get people to spread the word and upvote them. That's the only way to get the proper attention.
daemin 4y ago
I mean MSVC still has x86 (32 bit) projects as default, which also means that vcpkg is x86 by default. So to easily create and add x64 projects to a solution you need to use something like CMake otherwise you're doing a lot of manual work (this is why I started learning and using CMake). Also it uses the old style preprocessor by default which is not C++20 compatible, leading to writing a lot of very tricky macros in order to implement something that would otherwise be a couple of lines tops. Lots of legacy choices are the default, you need to use lots of other C++ tools in order to get a more modern development environment.
- bingo3131 4y ago
  I just made a new empty C++ project in MSVC 2022 and by default it generates compile options for both 32-bit and 64-bit, with 64-bit selected by default. The preprocessor mode can be manually changed trivially. Project Properties -> C/C++ -> Preprocessor -> Use Standard Confirming Preprocessor. And changing all of the other project properties are just as trivial (picking which C++ version you want, enabling/disabling language extensions, warning level, etc). I'm not sure changing the project properties via MSVC's project property changer counts as having to use "lots of other C++ tools"...
  - daemin 4y ago
    So they have. Though I doubt the utility of creating the 32 bit configuration because I don't see anyone creating 32 bit x86 Windows Desktop applications any time soon. They're more likely to create arm64 than x86. As for changing properties in MSVC, the issue I had was that when creating a new solution it would create a x86 project by default. So I would have to go in and create a new x64 configuration, change the project properties for all projects, then remove the x86 configuration from the projects and solution. Though whenever I added a new project it would default to x86 and I would have to redo all of the configuration steps again and once more delete the x86 configuration from the solution. I even tried using props files to try and simplify this but it never worked well enough. So for me it was much easier to learn how to use CMake properly, add the global settings to the top level CMakeLists.txt file, then a new project could be added by creating a new CMakeLists.txt file and rerunning CMake. There would be no need to mess around with the settings in the IDE worrying about if you forgot to update one or if the settings got out of sync.
    - kevingadd 4y ago
      For simpler applications, 32 bit will use less RAM without any noticeable disadvantages, so it's not the worst default in the world. Kind of questionable, perhaps. It does mean your software will work on older PCs, though!
      - 4y ago
planede 4y ago
/permissive or not, ternary operators have some bugs in all compilers. My favorite MSVC one: https://developercommunity.visualstudio.com/t/wrong-type-of-ternary-operator-true--/1698058 https://developercommunity.visualstudio.com/t/wrong-type-of-...
- edwinbalani 4y ago
  Yup, right on. We found a bug that crops up when a certain compiler (proprietary, not MSVC) tries to reuse the result of a float comparison originally made in a ternary expression. The compiler ends up omitting most of the rest of the function's assembly, which breaks things as much as you'd expect. (For bonus fun, our ternary expression was deep under about four layers of macro.)
- phaedrus 4y ago
  I like to tell the story of one time I tried the ternary expression, "return (cond)? result : throw;" and it crashed the compiler. (It was an older version of MSVC.)
samsaga2 4y ago
I don't care very much about the MSVC bugs. The problem is that compiler is very slow. Our 800 c++ files project takes 25 minutes to compile with MSVC, and 15 minutes with clang (Windows 10 with antivirus disabled and using cmake+ninja).
- wyldfire 4y ago
  Have you tried ccache btw? I don't know if it works with MSVC, but I think it should.
- w4rh4wk5 4y ago
  Despite not knowing anything about your code base, I recommend giving pre-compiled headers a try. I am currently working on a game + custom engine that is around 1M lines of C++ code. Thanks to pre-compiled headers and forward declarations, I can compile all of it in under 20 seconds (full rebuild, optimizations enabled). AMD Ryzen 9 7950X 16-Core Processor All code is stored on an NVMe drive, Windows Defender realtime protection is disabled. There's also a way to profile your build process with MSVC. It seems a bit daunting at first, but it's actually not that complicated: https://devblogs.microsoft.com/cppblog/introducing-c-build-insights/ https://devblogs.microsoft.com/cppblog/introducing-c-build-i...
  - jahnu 4y ago
    Yes! Pre compiled headers are an absolute must have for any large enough project in msvc. Well worth the effort.
- zone411 4y ago
  Hmm that seems excessively slow. I'm assuming you're using multithreaded compiling and SSDs? Any huge libraries? I'd try Build Insights. It seems worth investigating because 800 source files is not really that many.
  - samsaga2 4y ago
    Shitty computer plus SDD almost full. I have tried cmake target_precompile_headers, but it doesn't seem to work correctly with some third vendor libraries we are using (precisely the largest ones).
xvilka 4y ago
They should just abandon MSVC and invest into LLVM/Clang, like everyone else does. Will resolve a lot of incompatibility problems, and will bring more tools for developers.
- criddell 4y ago
  They have decent support for LLVM/Clang right now and the trend on that front is good. I think there’s value in competing compilers. I can’t see Microsoft abandoning their C++ compiler. The C++ compiler is a foundational technology for them and it’s something they want to own and control.
- logicchains 4y ago
  That'd be a step backwards. MSVC is actually much faster than Clang at implementing new C++ standards nowadays, not at all like before when it used to lag behind.
  - jcelerier 4y ago
    As someone who compiles c++20 code using the big three daily, MSVC claims conformance faster but in practice it's full of bugs and takes more time to be usable. E.g. when they claimed concept support, it was not possible to use requires-expression outside of a concept declaration e.g. no if constexpr (requires { foo; }) was a syntax error ; clang wasn't claiming concepts support but I couldn't find a thing that didn't work at the time. Same for coroutines, constexpr, my codebase at some point was littered with workarounds just for catering to MSVC's idea of conformance. Even today it's the compiler for which I have the most open bugs I think. And, to put the nail on the coffin, clang generates consistently faster code in my experience and its of many others, see e.g. this recent thread on r/cpp : https://www.reddit.com/r/cpp/comments/100vctp/msvc_vs_clang_performance_has_anyone_tested/ https://www.reddit.com/r/cpp/comments/100vctp/msvc_vs_clang_...
  - fluoridation 4y ago
    Clang is lagging behind because it's losing support.
hoten 4y ago
(luckily?) MSVC has been the only compiler I've used that has _crashed_ on me given certain code patterns. Here's a fun one that happens for only RelWithDebInfo 32bit [1]. The `Hero.{x,y}` properties here are a custom fixed precision number class with some implicit conversions to int, which I suspect being relevant to the crash. [1] https://github.com/ArmageddonGames/ZQuestClassic/blob/e678e9bd9b806d2f8bf054cfa2afd51ad318470c/src/zfix.h#L15-L32 https://github.com/ArmageddonGames/ZQuestClassic/blob/e678e9...
- 3836293648 4y ago
  GCC has crashed on me every time I've tried LTO. Though that is an optimisation flag and not a code pattern. Still a crash though

43 points by ibobev 4y ago

zone411 4y ago

/permissive- is now the default.

planede 4y ago
Yep, also /permissive is super non-conforming. My favorite /permissive "feature": `false` is a null-pointer constant: https://godbolt.org/z/Mzjfba1en https://godbolt.org/z/Mzjfba1en

hoseja 4y ago

I hate the Miscrosoft Developer Community reporting so much, the bot replies and the outsourced dismissals are so infuriating.

zone411 4y ago
My experience (C++): - 3 bugs marked as "Our teams prioritize action on product issues with broad customer impact" and never fixed - 1 bug fixed - 1 bug merged with another bug and fixed
- daemin 4y ago
  Really need to publicise issues in the tracker and get people to spread the word and upvote them. That's the only way to get the proper attention.

daemin 4y ago

I mean MSVC still has x86 (32 bit) projects as default, which also means that vcpkg is x86 by default. So to easily create and add x64 projects to a solution you need to use something like CMake otherwise you're doing a lot of manual work (this is why I started learning and using CMake). Also it uses the old style preprocessor by default which is not C++20 compatible, leading to writing a lot of very tricky macros in order to implement something that would otherwise be a couple of lines tops. Lots of legacy choices are the default, you need to use lots of other C++ tools in order to get a more modern development environment.

bingo3131 4y ago
I just made a new empty C++ project in MSVC 2022 and by default it generates compile options for both 32-bit and 64-bit, with 64-bit selected by default. The preprocessor mode can be manually changed trivially. Project Properties -> C/C++ -> Preprocessor -> Use Standard Confirming Preprocessor. And changing all of the other project properties are just as trivial (picking which C++ version you want, enabling/disabling language extensions, warning level, etc). I'm not sure changing the project properties via MSVC's project property changer counts as having to use "lots of other C++ tools"...
- daemin 4y ago
  So they have. Though I doubt the utility of creating the 32 bit configuration because I don't see anyone creating 32 bit x86 Windows Desktop applications any time soon. They're more likely to create arm64 than x86. As for changing properties in MSVC, the issue I had was that when creating a new solution it would create a x86 project by default. So I would have to go in and create a new x64 configuration, change the project properties for all projects, then remove the x86 configuration from the projects and solution. Though whenever I added a new project it would default to x86 and I would have to redo all of the configuration steps again and once more delete the x86 configuration from the solution. I even tried using props files to try and simplify this but it never worked well enough. So for me it was much easier to learn how to use CMake properly, add the global settings to the top level CMakeLists.txt file, then a new project could be added by creating a new CMakeLists.txt file and rerunning CMake. There would be no need to mess around with the settings in the IDE worrying about if you forgot to update one or if the settings got out of sync.
  - kevingadd 4y ago
    For simpler applications, 32 bit will use less RAM without any noticeable disadvantages, so it's not the worst default in the world. Kind of questionable, perhaps. It does mean your software will work on older PCs, though!
    - 4y ago

planede 4y ago

/permissive or not, ternary operators have some bugs in all compilers. My favorite MSVC one: https://developercommunity.visualstudio.com/t/wrong-type-of-ternary-operator-true--/1698058 https://developercommunity.visualstudio.com/t/wrong-type-of-...

edwinbalani 4y ago
Yup, right on. We found a bug that crops up when a certain compiler (proprietary, not MSVC) tries to reuse the result of a float comparison originally made in a ternary expression. The compiler ends up omitting most of the rest of the function's assembly, which breaks things as much as you'd expect. (For bonus fun, our ternary expression was deep under about four layers of macro.)
phaedrus 4y ago
I like to tell the story of one time I tried the ternary expression, "return (cond)? result : throw;" and it crashed the compiler. (It was an older version of MSVC.)

samsaga2 4y ago

I don't care very much about the MSVC bugs. The problem is that compiler is very slow. Our 800 c++ files project takes 25 minutes to compile with MSVC, and 15 minutes with clang (Windows 10 with antivirus disabled and using cmake+ninja).

wyldfire 4y ago
Have you tried ccache btw? I don't know if it works with MSVC, but I think it should.
w4rh4wk5 4y ago
Despite not knowing anything about your code base, I recommend giving pre-compiled headers a try. I am currently working on a game + custom engine that is around 1M lines of C++ code. Thanks to pre-compiled headers and forward declarations, I can compile all of it in under 20 seconds (full rebuild, optimizations enabled). AMD Ryzen 9 7950X 16-Core Processor All code is stored on an NVMe drive, Windows Defender realtime protection is disabled. There's also a way to profile your build process with MSVC. It seems a bit daunting at first, but it's actually not that complicated: https://devblogs.microsoft.com/cppblog/introducing-c-build-insights/ https://devblogs.microsoft.com/cppblog/introducing-c-build-i...
- jahnu 4y ago
  Yes! Pre compiled headers are an absolute must have for any large enough project in msvc. Well worth the effort.
zone411 4y ago
Hmm that seems excessively slow. I'm assuming you're using multithreaded compiling and SSDs? Any huge libraries? I'd try Build Insights. It seems worth investigating because 800 source files is not really that many.
- samsaga2 4y ago
  Shitty computer plus SDD almost full. I have tried cmake target_precompile_headers, but it doesn't seem to work correctly with some third vendor libraries we are using (precisely the largest ones).

xvilka 4y ago

They should just abandon MSVC and invest into LLVM/Clang, like everyone else does. Will resolve a lot of incompatibility problems, and will bring more tools for developers.

criddell 4y ago
They have decent support for LLVM/Clang right now and the trend on that front is good. I think there’s value in competing compilers. I can’t see Microsoft abandoning their C++ compiler. The C++ compiler is a foundational technology for them and it’s something they want to own and control.
logicchains 4y ago
That'd be a step backwards. MSVC is actually much faster than Clang at implementing new C++ standards nowadays, not at all like before when it used to lag behind.
- jcelerier 4y ago
  As someone who compiles c++20 code using the big three daily, MSVC claims conformance faster but in practice it's full of bugs and takes more time to be usable. E.g. when they claimed concept support, it was not possible to use requires-expression outside of a concept declaration e.g. no if constexpr (requires { foo; }) was a syntax error ; clang wasn't claiming concepts support but I couldn't find a thing that didn't work at the time. Same for coroutines, constexpr, my codebase at some point was littered with workarounds just for catering to MSVC's idea of conformance. Even today it's the compiler for which I have the most open bugs I think. And, to put the nail on the coffin, clang generates consistently faster code in my experience and its of many others, see e.g. this recent thread on r/cpp : https://www.reddit.com/r/cpp/comments/100vctp/msvc_vs_clang_performance_has_anyone_tested/ https://www.reddit.com/r/cpp/comments/100vctp/msvc_vs_clang_...
- fluoridation 4y ago
  Clang is lagging behind because it's losing support.

hoten 4y ago

(luckily?) MSVC has been the only compiler I've used that has _crashed_ on me given certain code patterns. Here's a fun one that happens for only RelWithDebInfo 32bit [1]. The `Hero.{x,y}` properties here are a custom fixed precision number class with some implicit conversions to int, which I suspect being relevant to the crash. [1] https://github.com/ArmageddonGames/ZQuestClassic/blob/e678e9bd9b806d2f8bf054cfa2afd51ad318470c/src/zfix.h#L15-L32 https://github.com/ArmageddonGames/ZQuestClassic/blob/e678e9...

3836293648 4y ago
GCC has crashed on me every time I've tried LTO. Though that is an optimisation flag and not a code pattern. Still a crash though