I mean you dont have to do all libraries modules vs all libraries headers. A library dep that supports modules, use modules. A library that doesn't, use headers

Don't mix and match for any given library, no reason for it

And it can be made to work but requires understanding global module semantics

Now I have to track the correct 50-odd headers from the STL, at which point I would just use them instead. Somewhat defeats the purpose of the exercise for me personally.

EDG still doesn't support modules, which means the default language server in VSC cpptools doesn't. clangd's support is experimental.

There's no reason to port your deps if you don't want to. That's orthogonal. Modules aren't an all-or-nothing proposition.

They work fine, intellisense is the big blocker.

Once you have a setup which works with them they're genuinely very pleasant to use. I won't be switching back for my personal projects.

You're in the worst case scenario. Medium number of files to scan, but already optimized to minimize the cost of preprocessing headers so you notice the perf hit of running the scanner.

That's why we added the flag to turn it off.

You hate to blame it all on Mormonism, but I've never found a better explanation for how Sanderson believes people work

The amount of "10 year C++ expert"s who don't know to invoke a compiler, or how PATH works, or how code is built in anything but the most abstract terms, remains concerning to me.

"This piece of shit build system always fails!"
"What's breaking?"
"I don't know"

Dog how is that not a skill issue

Once you lose control of what kind of environment your code is building in, where deps come from, what compiler features are available, etc, everything gets stranger from a build system point of view

Games, embedded, scientific, fintech, these fields are all use C++ but often talk past one another

lmao

The weirdest thing about games is that the developer is the one who builds their own code and ships the binary to the end user

That's actually a very odd state of affairs for much of the ecosystem. Math library people do not produce builds for every US supercomputer and couldn't if they tried

Of course, use whatever you want. If you only need to build in Visual Studio for Windows boxes, VS Projects remain a great solution.

That's a niche, and there are many others. The weird stuff exists in far more and on far stranger systems.

If C++ had a build system pre-standardization this would be the answer. Now everything is in conversation with the billions of existing lines of code.

Do write your own build system for your own new projects which enforces all the restrictions you like. CMake is for the existing weird stuff.

The entire evolution of presets have been "customer asked for presets to do this specific thing and are willing to pay for it" they have never once been a "we have a plan for presets and want them to work in this forethought and well designed way".

I'm not 100% what this is referring to but the answer is always "Nobody at Kitware uses presets and the feature has no upstream champions".

Whatever deficiencies exist aren't planned or "Won't Implement", they're "Don't Know" / "No manpower to work on it".

I would like to get off pkg-config's wild ride

Because GCC and Clang omit the call to the initialization symbol if the compiler knows (from the interface's BMI) that the initialization symbol is empty

This means you don't get a link error for leaving it off the link line, but relying on optimizations for build correctness is a code smell IMHO

The blog makes the same mistake we did with import std, you can never discard the generated object file.

It always needs to be linked for the module initialization symbol. Today, stdlibs don't ship this symbol. The question of "who is responsible for building/linking std.o" is unsolved.

To work in the C++ ecosystem you need to know how everything works. You need to know how your compiler works, linker, build system, dependency discovery, PATH, the shell, platform ABI, and more. Everything.

Problems arise when you try to skip something.

That's it. It's not good, but it is.

Prefixing "delete" with "::" limits it to looking up the dealloc func in the global namespace, rather than in the scope of the ptr's type

Since you never call the class dealloc func (which would call the global dealloc func with the correct size), the global dealloc func is used with sizeof(*ptr)

So it almost certainly isn't generating any value, but those also aren't the words he said

It's deeply worthless. Dangerous even if the user isn't fluent in the subject they're using it for, because some level of fluency is sometimes necessary to identify how bad its codegen is.

After a month of working with Copilot I'm forced to assume anyone singing its praises is a grifter.

Trying to think of Linux as a consumer ecosystem is fundamentally broken.

It's not an Apple or Android device, it's not a packaged product. It's a building block used by professionals.

It's like going to a lumber yard and complaining about the fracturing of the wood ecosystem.