Item — HN Reader

I fully agree that this is the cardinal sin of C++. I think that C still offers much better encapsulation by using interfaces based on incomplete struct types. While I understand your point regarding inline, there are some comments I would like to make: It is now there and removing it would break existing code. The alternative are often macros, but inline functions where they can replace macros are better and the compiler can decide not to inline when it does not make sense. LTO is an alternative, but does not work across library boundaries, and also has a very substantial compile-time cost.

Compiling with a new language mode does not force you to move variable declarations to the point of initialization, but you would now have the option to improve the code in this way when it makes sense. It is difficult to see this as an disadvantage. My point is that moving it to a new language version would usually not require changes to the code, except where the old modes were dangerous. So I would expect to find serious bugs when doing this.

2 comments

> ... So I would expect to find serious bugs when doing this.

That's actually a good point hmmm (not in case of this specific assembler, which seems to be quite robust and well-written), and even if there would be serious memory corruption errors lurking, they would be contained because the assemblers runs in a WASM VM.

For projects that are still maintained, a "moving standard" isn't that much of a problem, after all we've been conditioned that every new compiler update adds new warnings which "break" existing code ;)

...there is a certain value in taking a "finished/frozen" project and integrate that into a new project without requiring code changes though.

I'm sure there must be a good middle-ground for C, where obviously bad and outdated language features (starting with leftovers from the K&R era) can be removed without causing too much breakage even on most old code ... but then, why keep 'inline' ;P

Which C++ fixed with modules. Something that most likely C will never have.

> Something that most likely C will never have.

...rather, doesn't need. C++ modules just (potentially at least) fix a problem that C++ created in the first place (exploding build times because of complex template code in stdlib headers).

Also, I have yet to see clear indications that C++ modules drastically improve build times in real world projects.

Back when I had to develop in C, I would routinely wait for 1h builds.

The trick to make them faster is the same as with C++, never compile everything from source unless required, this includes template code for common type parameters.

As for compile times see Microsoft Office modules migration, or that VC++ import std in C++23 is faster than a plain #include <iostream>.