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.
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"...
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.
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!
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.
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.
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.
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.
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.)
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.
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.
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.
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.
(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.
32 comments
[ 4.5 ms ] story [ 83.9 ms ] threadhttps://godbolt.org/z/Mzjfba1en
- 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
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.
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"...
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.
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.
https://en.wikipedia.org/wiki/X32_ABI
[0] https://lwn.net/Articles/774734/
https://developercommunity.visualstudio.com/t/wrong-type-of-...
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.)
"return (cond)? result : throw;"
and it crashed the compiler. (It was an older version of MSVC.)
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 don't know if it works with MSVC, but I think it should.
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.
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_...
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...