MSVC: The Devourer of Const(ibob.bg)
ibob.bg
MSVC: The Devourer of Const
https://ibob.bg/blog/2023/01/04/msvc-allows-moving-from-const/
7 comments
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
/permissive- is now the default.
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
I hate the Miscrosoft Developer Community reporting so much, the bot replies and the outsourced dismissals are so infuriating.
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
- 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
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.
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.
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.
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"...
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"...
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.
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.
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!
32 bit mode has fewer registers and CPU extensions to use. On Linux there are experiments with an ABI with 32 bit pointers, but otherwise using the full feature set of AMD64, it's called the x32 ABI.
https://en.wikipedia.org/wiki/X32_ABI
https://en.wikipedia.org/wiki/X32_ABI
And it works so well! I remember doing some particle rendering and tree walking benchmark on it and it was really really faster, like 15% consistently
Interesting! I'm actually tempted to put x32 Debian on a low-end netbook I have. I wonder if it's possible with multiarch and try with a few apps first.
Might get removed in the future [0], though!
[0] https://lwn.net/Articles/774734/
[0] https://lwn.net/Articles/774734/
Ah, too bad. I wonder why it needs a distinct Linux syscall interface though. There must be a reason why the existing x86_64 or x86 syscalls could not be used for x32.
To target older PCs you also need to target something like Windows 7 rather than Windows 10 or later.
It also depends how you write your code because there are many ways to reduce memory usage, for example switching to arrays and 32bit indexes instead of using native sized pointers. Can also use smaller data types than size_t etc.
Having both x64 and x86 as configurations by default is a step forward, but realistically I wouldn't want any configuration in my solution which does not work and is not supported.
It also depends how you write your code because there are many ways to reduce memory usage, for example switching to arrays and 32bit indexes instead of using native sized pointers. Can also use smaller data types than size_t etc.
Having both x64 and x86 as configurations by default is a step forward, but realistically I wouldn't want any configuration in my solution which does not work and is not supported.
/permissive or not, ternary operators have some bugs in all compilers. My favorite MSVC one:
https://developercommunity.visualstudio.com/t/wrong-type-of-...
https://developercommunity.visualstudio.com/t/wrong-type-of-...
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.)
"return (cond)? result : throw;"
and it crashed the compiler. (It was an older version of MSVC.)
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.)
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.)
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).
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-i...
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-i...
Yes! Pre compiled headers are an absolute must have for any large enough project in msvc. Well worth the effort.
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.
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).
If this is for a business, why not replace the computer? If you can save a lot of time per build it shouldn’t take very long for a new computer or upgraded SSD to pay for itself.
Have you tried ccache btw?
I don't know if it works with MSVC, but I think it should.
I don't know if it works with MSVC, but I think it should.
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.
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.
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.
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.
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_...
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_...
Clang is lagging behind because it's losing support.
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/e678e9...