C++ Features Banned By Google

[H. S. Teoh]

On Tue, Jan 27, 2026 at 08:22:12PM +0000, Gregor Mückl via Digitalmars-d wrote:
> On Saturday, 24 January 2026 at 17:39:21 UTC, H. S. Teoh wrote:
[...]
> > Possibly.  I'm not familiar with C++ modules: what exactly does it
> > entail?  You have to precompile headers before they can be used as a
> > module?  That sounds unusually onerous, compared to, say, D, where
> > the compiler just parses the source file directly and the user
> > doesn't have to do anything extra.
[...]
> I'm not too familiar with modules, but the C++ modules really have a
> level of complexity that is staggering to my mind. It's not that one
> file is one module (1:1). That would have been too easy ;).
> 
> Instead, you can separate modules out over several files (module
> partitions). They form the same module by virtue of having the same
> name in their module statements. But not all partitions are equal,
> either. Some are interfaces (their content is visible externally),
> some internal (their content is only visible internally).

Ouch.  That sounds palpably painful.  Though consistent with C++'s
tendency to engineer over-complex solutions that try to cover every
single use case imaginable, resulting in a monstrous mess that even its
own designers don't fully comprehend.


> Of course, all of this still interacts somehow with header files and
> preprocessor macros.

Now I have yet another reason to stay away from C++ like the plague. :-D


> AFAIK the standard assumes that modules are compiled into some kind of
> self-contained artifacts that can then be imported by other modules
> without a need for separate header files. So in my understanding, a
> compiler has to work with some kind of superset of precompiled headers
> and object files.

Anybody and his neighbour's dog is capable of adding yet another layer
of abstraction to an already over-complex mess, thus compounding the
original problem and making it worse.

It take genius, and not a small amount of boldness, to invent a solution
that actually simplifies the problem to the point that its solution
becomes obvious to anyone who looks at it.

Some of C++'s design decisions remind me of an expression one of my CS
profs used to use, in reference to programming assignments by
inexperienced freshmen who, failing to grasp the crux of the original
problem, add to it by writing code that does all kinds of tangential,
but ultimately irrelevant, things, in a futile effort to make it look
like some progress is being made.  She called it "squirrely code": code
that, like squirrels who, having buried a cache of nuts for the winter
but subsequently forgotten where it was, run to and fro looking for
them, spending much time and energy seemingly doing a lot but actually
accomplishing nothing.

Sometimes these over-engineered, over-complex C++ "solutions" feel like
the design equivalent of squirrely code, promising to solve every
problem you can conceive of yet either failing to do so, or does so in
the most gratuitously convoluted way ever, in the process introducing
whole new classes of problems that, in turn, invite even more squirrels
to the party.


T

-- 
There are four kinds of lies: lies, damn lies, and statistics.