Nothing particularly notable here. A lot of it seems to be 'We have something in-house designed for our use cases, use that instead of the standard lib equivalent'.
The rest looks very reasonable, like avoiding locale-hell.
Some of it is likely options that sand rough edges off of the standard lib, which is reasonable.
There are yet more interesting docs in the parent directory :)
https://chromium.googlesource.com/chromium/src/+/main/styleg...
Where does it list the preferred alternatives to banned features?
For example:
> The <filesystem> header, which does not have sufficient support for testing, and suffers from inherent security vulnerabilities.
Is there a way to make this formal, like in the code, making the compiler complain when you try to use these features?
The banned list proves that context matters more than having the newest tools. These features work well for small apps but they cause problems in a project this size.
It's remarkable to me how many codebases ban exceptions and yet, somehow, people still insist they're good.
I think reasonable people can disagree about whether C++ exceptions are "good" or not.
There are things you can't do easily in C++ without using exceptions, like handling errors that happen in a constructor and handling when `new` cannot alloc memory. Plus, a lot of the standard library relies on exceptions. And of course there's the stylistic argument of clearly separating error-handling from the happy-path logic.
I won't argue that it's popular to ban them, though. And often for good reasons.
> Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. ... Things would probably be different if we had to do it all over again from scratch.
They are clearly not against them per se. It simply wasn't practical for them to include it into their codebase.
And I think a lot of the cons of exceptions are handled in languages like F#, etc. If f calls g which calls h, and h throws an exception, the compiler will require you to deal with it somehow in g (either handle or explicitly propagate).
My issue with exceptions is also practical. If they didn't introduce significant stability issues, I'd have no problem. As it stands, it's impossible to write robust software that makes use of C++ exceptions.
> the compiler will require you to deal with it somehow in g
I agree, this is the sensible solution.
In low-level systems software, which is a primary use case for C++, exceptions can introduce nasty edge cases that are difficult to detect and reason about. The benefits are too small to justify the costs to reliability, robustness, and maintainability.
Exceptions in high-level languages avoid many of these issues by virtue of being much further away from the metal. It is a mis-feature for a systems language. C++ was originally used for a lot of high-level application code where exceptions might make sense that you would never use C++ for today.
If you forget to handle a C++ exception you get a clean crash. If you forget to handle a C error return you get undefined behavior and probably an exploit.
Exceptions are more robust, not less.
Yeap. forgetting to propagate or handle an error provided in a return value is very very easy. If you fail to handle an exception, you halt.
> "In low-level systems software, which is a primary use case for C++, exceptions can introduce nasty edge cases that are difficult to detect and reason about. The benefits are too small to justify the costs to reliability, robustness, and maintainability."
Interestingly, Microsoft C / C++ compiler does support structured exception handling (SEH). It's used even in NT kernel and drivers. I'm not saying it's the same thing as C++ exceptions, since it's designed primarily for handling hardware faults and is simplified, but still shares some core principles (guarded region, stack unwinding, etc). So a limited version of exception handling can work fine even in a thing like an OS kernel.
> In low-level systems software, which is a primary use case for C++
I can assure you: Most C++ SW is not written for low-level.
> exceptions can introduce nasty edge cases that are difficult to detect and reason about.
That's true, except for languages that ensure you can't simply forget that something deep down the stack can throw an exception.
BTW, I'm not saying C++'s exceptions are in any way good. My point is that exceptions are bad in C++, and not necessarily bad in general.
The model of communicating errors with exceptions is really nice. The implementation in C++ ABI's is not done as well as it could be and that results in large sad path perf loss.
C++ exceptions are fast for happy path and ABI locked for sad path. They could be much faster than they are currently. Khalil Estell did a few talks/bunch of work on the topic and saw great improvements. https://youtu.be/LorcxyJ9zr4
Exceptions are actually a form of code compression. Past some break even point they are a net benefit, even in embedded codebases. They're "bad" because the C++ implementation is garbage but it turns out it's possible to hack it into a much better shape:
There is no such thing as the 'C++ implementation' of exceptions. Each vendor can do it differently.
Is this correct? I don't know F# but I thought it had unchecked exceptions. How does it handle using C# libs that throw unchecked exceptions?
My memory of F# is very rusty, but IIRC, there are two types of error handling mechanisms. One of them is to be compatible with C#, and the other is fully checked.
The “pros” list is exceptionally weak. This was clearly written by someone who doesn’t like exceptions. Can’t blame them.
Most codebases that ban exceptions do it because they parrot Google.
Google’s reasons for banning exceptions are historical, not technical. Sadly, this decision got enshrined in Google C++ Style Guide. The guide is otherwise pretty decent and is used by a lot of projects, but this particular part is IMO a disservice to the larger C++ ecosystem.
I agree. I've worked on large C++ code bases that use exceptions, and they've never caused us any real problems.
They're good for exceptional situations where foundamental, core assumptions are broken for some reason.
In such scenario there's no error recovery, software is expected to shutdown and raise loud error.
Yet, if you can only explain an exception using the word ‘exception’ you’re not making any head way.
I like the idea of an exception as a way to blow out of the current context in order for something else to catch it and handle in a generic manner. I don’t like the idea of an exception to hide errors or for conditional logic because you have to know what is handling it all. Much easier to handle it there and then, or use a type safe equivalent (like a maybe or either monad) or just blow that shit up as soon as you can’t recover from the unexpected.
If you're planning on shutting down, what's the fundamental difference between throwing an exception, vs simply complaining loudly and calling exit() ..?
Sometimes it’s useful to handle the exception somewhere near its origin so you can close related resources, lockfiles, etc. without needing a VB6 style “On Error GoTo X” global error handler that has to account for all different contexts under which the exceptional situation might have occurred.
Your process can crash or be killed at any moment anyway. Depending on in-band cleanup is not reliable.
Sure, but there are many cases where you don't have to halt because you can cleanup and carry on.
> a VB6 style “On Error GoTo X” global error handler that has to account for all different contexts under which the exceptional situation might have occurred
... That seems like a pretty accurate description of how exception handling mechanisms are implemented under the hood. :)
I use asserts for this purpose.
Looking at this ban list, they've removed everything from C++ that makes it fun.
On banning exceptions:"Things would probably be different if we had to do it all over again from scratch."
https://google.github.io/styleguide/cppguide.html#Exceptions
Exceptions are banned, but an exception is made for Windows.
grep'd "exception" and "Windows", tl;dr only Windows reference is for `[[no_unique_address]]`. Therefore I am probably missing a joke :)
Might be referring to SEH ..? Just a wild guess
Ah, found it: in the style guide linked from this article. https://google.github.io/styleguide/cppguide.html#Exceptions
Modules are banned - they should have just copied D modules.