M'ok, 2019 has some problems with C++20, you should set the C++ language standard to c++:latest instead C++20.
I'd recommend getting VS 2022, it works better than 2019. And it can use the C++20 language standard instead of latest.
Of course VS 2022 requires you are Windows x64. If you are 32-bit you are kinda stuck with VS 2019.
I have both 2019 and 2022 installed, Community editions, and I've found 2022 to be less twitchy than 2019, especially when using C++20 language features.
And consider not using precompiled headers if you can, they've been causing problems for a long time, since VS 6 that I've noticed. The very small amount of time saved using them is not worth the problems they can cause.
When I start a new project/solution I use the Windows Desktop Wizard project template so I can specify what the application type is -- Console, Desktop (WinAPI), Dynamic Library or Static Library -- and select the "Empty Project" check box. No files are added to the project so I can add what files I need/want. Now I don't have to deal with precompiled headers. Less problems that way. :)
The personal project I have is kind of a "rip-off" from work as I've been assigned the memory management of our projects, and considering the size of the codebase, solutions, etc, PCH is a solid solution to spare hours, maybe even days to compile for ourselves.
Apart from trying to see the positives in it, it's what's been used for a long time, and deconstructing the PCH might not be very desirable.
I make sure that VS is up to date, and I was hoping that updating it would solve it, but alas, it didn't.
I have tried a couple things;
- Clean solution -> Build Solution
- Clean Solution -> Rebuild Solution
- Fresh "install" of the project through version control -> Build
Well, I've set the Precompiled Header to "Use (/Yu)", the name for the header file that is the PCH, and set a PCH Output File as well.
Yeah it seems like PCH makes things a bit unstable.
I'm not too well versed in it, but it really just seems like there's not enough space for the PCH to do it's thing, as building it 2-3 times in a row just removes the issue entirely at the last build and runs as it should.
So the size of a PCH I can understand can get a bit big, however the bit where it "fails to allocate virtual memory", I fail to see the connection.
The difference in compilation time would be enormous
Are you sure about that? Have you actually done tests? The MSVC++ compiler is a lot more efficient than it used to be. The underlying compiler in 2022 is better, marginally, than 2019's. 2019 is still speedy when doing incremental builds.
Right now using precompiled headers is a huge time waste since you can't get your project(s) to compile.
Not using PCH will take some extra time the first compilation, especially if done as a full rebuild. Builds after that should be speedier since they will be incremental builds.
Any time I create a new project in VS I always choose to not use precompiled headers, whether I use modules or not. Have been doing that for years, so C++20 introducing modules hasn't been a big change in compilation speeds for me.
One thing to note about using modules, the first time when using a new import the compile time increases slightly as VS compiles the referenced module. Every compile afterwards is speedier because the module is already compiled.
Now, about user created modules the same holds true, as long as the module isn't modified. First time/make a change takes a wee bit longer.
Forget using the travesty of the MS workaround of std.core. Importing that is as troublesome as precompiled headers in my experience. Just change the C++ stdlib includes to import and you're good to go.
My projects are usually smallish so any promised advantage modules were supposed to have about being speedier than includes is kinda hard to document. The lengthiest compile time for a single project I can remember was about 45 seconds. Compile times using modules seems to be marginally quicker.
Converting a pre-existing include headers project is either:
1. as simple as changing a couple of keywords in the file. If it's a header change the file extension. If it's a source file that accompanies the header change how it is compiles to an internal partition.
2. If the files are code interlocked, one needs another to work, converting to modules can be more time consuming vs. the benefits of using modules. At least that has been my limited experience of trying to convert a pre-modules project to modules.
did you try the derp move of deleting the pch files and letting it rebuild them from scratch? takes a long time, but if they are corrupted, its over. I work on a big project as well and when those go bad (they do in 2019, frequently enough) or the PDB goes bad there is nothing for it but sitting out a longer compile.
All the way back to visual studio 5.0 (I started on 1.0, but that was another story, 5.0 is where I started working with it daily and in depth) the rule of the day was to turn PCH off right away on new projects. It has never worked right, and this is going on 25+ years of having it. Edit-continue PDB is also high risk of failing. Good ideas that sorta work but never quite got a full debugging.
you can try to get it working. One of the failure points is when the files get too big, though. Breaking the code into many small projects that work together to produce a bigger project is a big help.