www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++ Features Banned By Google

reply Walter Bright <newshound2 digitalmars.com> writes:
https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/c++-features.md

This is an interesting document. Of particular note is banning the use of 
exceptions:

https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/c++-features.md#exception_banned

An interesting rationale thread here:

https://news.ycombinator.com/item?id=46738741

Modules are banned!

https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/c++-features.md#modules-banned
Jan 23
next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Fri, Jan 23, 2026 at 02:48:24PM -0800, Walter Bright via Digitalmars-d wrote:

 https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/c++-features.md
 
 This is an interesting document. Of particular note is banning the use
 of exceptions:
 
 https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/c++-features.md#exception_banned
 
 An interesting rationale thread here:
 
 https://news.ycombinator.com/item?id=46738741


Seems mostly historical than anything else.  Google probably chose that
route to minimize breakage of legacy code.  Would they go the same route
if they were to start from scratch today?  I don't know.  But this looks
more like a case of inertia of legacy codebases than a decision driven
by technical merit.



 Modules are banned!
 
 https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/c++-features.md#modules-banned


Rationale seems to be inadequate support in Clang and GN (sic - what's
GN?), not that modules themselves are bad.  I haven't been keeping up
with C++, though, so I've no idea whether the module system is actually
any good.

In any case, a large existing C++ codebase probably isn't very conducive
to adopting a feature like modules.  Knowing how legacy C++ codebases
tend to be, there's probably a ton of hacks based on the old #include
system inherited from C that will break in horrible ways when you try to
slap the new modules system onto an existing codebase / build system.
It will likely result in much churn with no real benefit, so I can see
why they're holding back for the time being.


T

-- 
Build a man a fire, and he is warm for a night. Set a man on fire, and
he is warm for the rest of his life.
Jan 23
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Friday, 23 January 2026 at 23:58:15 UTC, H. S. Teoh wrote:

 Rationale seems to be inadequate support in Clang and GN (sic - 
 what's GN?)


A build system generator 'generate ninja': 
https://gn.googlesource.com/gn/
Jan 23
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/23/2026 3:58 PM, H. S. Teoh wrote:

 Rationale seems to be inadequate support in Clang and GN (sic - what's
 GN?), not that modules themselves are bad.


My suspicion is that it's unusually difficult to implement. It requires 
precompiled files to be written out - my experience with that (precompiled 
headers) is it is overly complex.
Jan 24
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Sat, Jan 24, 2026 at 09:29:06AM -0800, Walter Bright via Digitalmars-d wrote:

 On 1/23/2026 3:58 PM, H. S. Teoh wrote:

 Rationale seems to be inadequate support in Clang and GN (sic -
 what's GN?), not that modules themselves are bad.


 
 My suspicion is that it's unusually difficult to implement. It
 requires precompiled files to be written out - my experience with that
 (precompiled headers) is it is overly complex.


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.


T

-- 
"Hi." "'Lo."
Jan 24
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/24/2026 9:39 AM, H. S. Teoh wrote:

 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.


My initial thought on modules for D is precompiling them. But I soon realized 
that it was faster to just parse them than read in a binary file and sort it 
into D's internal data structures.

Another problem with precompiled modules is it will add much complexity to the 
build system.
Jan 25
parent user1234 <user1234 12.de> writes:
On Sunday, 25 January 2026 at 18:47:17 UTC, Walter Bright wrote:

 On 1/24/2026 9:39 AM, H. S. Teoh wrote:

 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.


 My initial thought on modules for D is precompiling them. But I 
 soon realized that it was faster to just parse them than read 
 in a binary file and sort it into D's internal data structures.

 Another problem with precompiled modules is it will add much 
 complexity to the build system.


bahaha who needs precompiled headers when you have a module 
system.

They are so sick.
Jan 26
prev sibling parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Saturday, 24 January 2026 at 17:39:21 UTC, H. S. Teoh wrote:

 On Sat, Jan 24, 2026 at 09:29:06AM -0800, Walter Bright via 
 Digitalmars-d wrote:

 On 1/23/2026 3:58 PM, H. S. Teoh wrote:

 Rationale seems to be inadequate support in Clang and GN 
 (sic - what's GN?), not that modules themselves are bad.


 
 My suspicion is that it's unusually difficult to implement. It 
 requires precompiled files to be written out - my experience 
 with that (precompiled headers) is it is overly complex.


 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.


 T


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).

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

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.
Jan 27
parent "H. S. Teoh" <hsteoh qfbox.info> writes:
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.
Jan 27
prev sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 24/01/2026 11:48 AM, Walter Bright wrote:

 https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/c+ 
 +-features.md
 
 This is an interesting document. Of particular note is banning the use 
 of exceptions:
 
 https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/c+ 
 +-features.md#exception_banned


And in Go which was designed for Google and Google alone, they have 
panics and recover.

https://go.dev/blog/defer-panic-and-recover

A little like our Error hierarchy except with a lot more type system 
inference and magic. Without the Throwable class, and more of the throw 
a int value kind of thing.
Jan 24