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.
It's weird to me, as the former lead maintainer of this page for ten years or so, that this got submitted to both r/c++ and HN on the same day. Like... what's so exciting about it? Was there something on the page that caught someone's eye?
> We have something in-house designed for our use cases, use that instead of the standard lib equivalent
Yea, you encounter this a lot at companies with very old codebases. Don't use "chrono" because we have our own date/time types that were made before chrono even existed. Don't use standard library containers because we have our own containers that date back to before the STL was even stable.
I wonder how many of these (or the Google style guide rules) would make sense for a project starting today from a blank .cpp file. Probably not many of them.
For the containers in particular this makes a lot of sense because the C++ stdlib containers are just not very good. Some of this is because C++ inherited types conceived as pedagogic tools. If you're teaching generic programming you might want both (single and double) extrusive linked list types for your explanation. But for a C++ programmer asking "Which of these do I want?" the answer is almost always neither.
The specification over-specifies std::unordered_map so that no good modern hash table type could implement this specification, but then under-specifies std::deque so that the MSVC std::deque is basically useless in practice. It requires (really, in the standard) that std::vector<bool> is a bitset, even though that makes no sense. It sometimes feels as though nobody on WG21 has any idea what they're doing, which is wild.
Don't use standard library containers because we have our own containers that date back to before the STL was even stable.
Flashback to last job. Wrote their own containers. Opaque.
You ask for an item from it, you get back a void pointer. It's a pointer to the item. You ask for the previous, or the next, and you give back that void pointer (because it then goes through the data to find that one again, to know from where you want the next or previous) and get a different void pointer. No random access. You had to start with the special function which would give you the first item and go from there.
They screwed up the end, or the beginning, depending on what you were doing, so you wouldn't get back a null pointer if there was no next or previous. You had to separately check for that.
It was called an iterator, but it wasn't an iterator; an iterator is something for iterating over containers, but it didn't have actual iterators either.
When I opened it up, inside there was an actual container. Templated, so you could choose the real inside container. The default was a QList (as in Qt 4.7.4). The million line codebase contained no other uses; it was always just the default. They took a QList, and wrapped it inside a machine that only dealt in void pointers and stripped away almost all functionality, safety and ability to use std::algorithm
I suspect but cannot prove that the person who did this was a heavy C programmer in the 1980s. I do not know but suspect that this person first encountered variable data type containers that did this sort of thing (a search for "generic linked list in C" gives some ideas, for example) and when they had to move on to C++, learned just enough C++ to recreate what they were used to. And then made it the fundamental container class in millions of lines of code.
> I wonder how many of these (or the Google style guide rules) would make sense for a project starting today from a blank .cpp file. Probably not many of them.
The STL makes you pay for ABI stability no matter if you want it or not. For some use cases this doesn't matter, and there are some "proven" parts of the STL that need a lot of justification for substitution, yada yada std::vector and std::string.
But it's not uncommon to see unordered_map substituted with, say, sparsehash or robin_map, and in C++ libraries creating interfaces that allow for API-compatible alternatives to use of the STL is considered polite, if not necessarily ubiquitous.
> I wonder how many of these (or the Google style guide rules) would make sense for a project starting today from a blank .cpp file. Probably not many of them.
That also depends on how standalone the project is. Self-contained projects may be better off with depending on standard library and popular third-party libraries, but if a project integrates with other internal components, it's better to stick to internal libraries, as they likely have workarounds and special functionality specific to the company and its development workflow.
I'd argue that the optimum was in long run to migrate to the standard version, that everyone (e.g. new employees) know. Replacing the usually particular (or even weird) way implemented own flavour.
I know, I know, long run does not exists in today's investor dominated scenarios. Code modernization is a fairytale. So far I seen no exception in my limited set of experiences (but with various codebases going back to the early 90's with patchy upgrades here and there, looking like and old coat fixed many many times with diverse size of patches of various materials and colour).
Somewhat notable is that `char8_t` is banned with very reasonable motivation that applies to most codebases:
> Use char and unprefixed character literals. Non-UTF-8 encodings are rare enough in Chromium that the value of distinguishing them at the type level is low, and char8_t* is not interconvertible with char* (what ~all Chromium, STL, and platform-specific APIs use), so using u8 prefixes would obligate us to insert casts everywhere. If you want to declare at a type level that a block of data is string-like and not an arbitrary binary blob, prefer std::string[_view] over char*.
In a lot of places, they point out the std implementation is strictly inferior to theirs in some way, so its not always organizational inertia, it's that the C++ standard types could have been designed strictly better with no tradeoff.
> 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 bulk of the restrictions are justified as "Banned in the Google Style Guide."
In turn the Google Style Guide bans most of the features because they can't/won't refactor most of their legacy code to catch up with post C++0x.
So even then these guidelines are just a reflection of making sure things stay safe for upstream and downstream consumers of Google's largely unmaintained codebase.
I don't think that's an accurate representation. There are a few features like that, but the majority of things banned in the Google style guide are banned for safety, clarity, or performance concerns. Usually in such cases Google and/or Chromium have in-house replacements that choose different tradeoffs.
Not an Googler, but my, probably way too much romanticized, understanding of Google was that they never ask you about specific tech because for everything there's an in-house version.
The problem is that too many people drank too much koolaid and trying to parrot everything to a letter without understanding the bigger picture.
The best example would be Kubernetes. Employed by many orgs that have 20 devs and 50 services.
Reasonable summary. There's some massive NIH syndrome going on.
Another piece is that a lot of stuff that makes sense in the open source world does not make sense in the context of the giant google3 monorepo with however many billions of lines of code all in one pile.
A good decision. I tried to use it once and realized that it can't even work with UTF-8 properly. It's a mystery for me how such flawed design was standardized at all.
You almost never see a list of banned Java features (or even banned C# features). On the other hand any serious C++ development team is going to have a list of banned features. Java eliminated the features that you would want to ban.
This seems factually incorrect and ignorant of history. Java has tons of things which shouldn't be used. Serialization (use Jackson now, not the built-in stuff), date/time (there's an entirely different namespace so you don't accidentally use garbage classes), etc.
C# similarly has old warts that are discouraged now. .NET Framework is a great example (completely different from modern c#, which used to be called "dotnet core"). WPF and MAUI are also examples. Or when "dynamic" was used as a type escape hatch before the type system advanced to not need it. ASP being incompatible with ASP.NET, the list goes on.
They're just languages, there's no reason to pretend they're perfect.
> C# similarly has old warts that are discouraged now. .NET Framework is a great example (completely different from modern c#, which used to be called "dotnet core"). WPF and MAUI are also examples. Or when "dynamic" was used as a type escape hatch before the type system advanced to not need it. ASP being incompatible with ASP.NET, the list goes on.
Almost all of this is incorrect or comparing apples to oranges.
.net framework and .net core are runtime and standard library impl, not languages. C# is a language that can target either runtime or both. Framework is still supported today, and you can still use most modern C# language features in a project targeting it. WPF and Maui are both still supported and widely used. ASP predates .net - c# was never a supported language in it. ASP.net core has largely replaced ASP.net, but it's again a library and framework, not a language feature.
Dynamic in c# and the dlr are definitely not widely used because it's both difficult to use safely and doesn't fit well with the dominant paradigm of the language. If you're looking for STD lib warts binaryserializer would have been an excellent example.
C# can be used in both .NET Framework and modern .NET (ex-core). In fact, it is possible for a C# project to target both .NET Framework and .NET with the exact same code, or to target to .NET Standard, where the same .DLL file can be loaded by both. Since the old Framework is in maintenance mode, some modern language features will not work there, but you can still be productive with the old framework.
Dynamic is largely unnecessary, and it was unnecessary even when it was introduced.
ASP and ASP.NET are completely unrelated. ASP was designed to allow dynamic webpages to be written in VBScript (like CGI). This is not something you want to do in modern languages.
In C#, you would normally implement rules like this with a custom Roslyn Analyzer or with https://github.com/dotnet/roslyn/blob/main/src/RoslynAnalyze.... It’s fair to say C# projects tend to have smaller denylists than mature C++ projects, but banned APIs definitely exist in mature C# projects.
I think Java has plenty of features that end up implicitly banned at least. e.g. you will really never see a `java.util.Vector` in any modern code base. No one `implements Serializable` anymore in practice. `Objects.equals()` and `Objects.hashCode()` get you through 99% of equals/hash code implementations. The list goes on.
I guess the difference is it's rarely "dangerous" or "hard to reason about" using the old features unlike what I see in the C++ list. Java replaces things with better things and momentum shifts behind them kind of naturally because the better things are objectively better.
As a Java programmer I can only think of one thing:
Reflection - unless you really need to do something fancy almost certainly a very bad idea in normal application code.
Other than that it’s either just limiting yourself to a specific JVM version or telling people not to use old syntax/patterns that were replaced with better options long ago.
Unless you develop games in Unity, and have banned C# features like classes or LINQ (because they allocate on heap and Unity garbage collector is bad and make your game to micro freeze / stutter). Sure there are cases where classes are fine (singletons, pooling), but still...
People that keep bringing this up always miss the rationable that Google code was written initially in a C style that isn't exception safe.
Key takeaway => "Things would probably be different if we had to do it all over again from scratch."
"On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.
Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in a new project. The conversion process would be slow and error-prone. We don't believe that the available alternatives to exceptions, such as error codes and assertions, introduce a significant burden.
Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. Because we'd like to use our open-source projects at Google and it's difficult to do so if those projects use exceptions, we need to advise against exceptions in Google open-source projects as well. Things would probably be different if we had to do it all over again from scratch."
I'm quite happy to NOT have exceptions. I think they're a mistake as a language feature. What we need is first -class support for returning errors and propagating them, like what zig does. The next best thing are those RETURN macros that Google uses.
Both parts of your sentence refer to the Google style guide. This doc isn't the Google style guide. It's the Chromium modern c++ features doc. We don't talk about exceptions or platform-specific stuff (save a note on [[no_unique_address]]) in this doc.
Gonna venture a guess and say probably https://www.chromium.org/developers, as that's where all the information for folks who actually need to know that kind of thing lives.
I'm not a c++ user but i'm pretty sure you should be able to pull-off a macro to do that ; in c you could alias the lib for something that breaks + alert ; I don't know how I would integrate such additional compiler checks in rust for other kinds of rules however - it's interesting to think about
Rust has been better than C++ about marking where there's a foot gun and where practical just nerfing it. core::mem::uninitialized() is an example. In 2016 if you'd said "Initializing my Doodad is too expensive, what do I do?" you might be pointed at the (unsafe) core::mem::uninitialized() which "initializes" any variable, such as your Doodad but er, doesn't actually initialize it.
But that's a foot gun, there are niche cases where this crazy stunt actually is correct (ZSTs are one), but in general the compiler was in effect licensed to cause absolute mayhem because this isn't a Doodad at all, which isn't what you wanted. So, they did three things:
1. Made a new type wrapper for this purpose, MaybeUninit<Doodad> might not be a Doodad yet, so we can initialize it later and until then the compiler won't set everything on fire but it's the same shape as the Doodad.
2. Marked core::mem::uninitialized deprecated. If you use it now the compiler warns you that you shouldn't do that.
3. De-fanged it by, despite its name, scrawling the bit pattern 0x01 over all the memory. The compiler can see this has some particular value and for common types it's even valid, a bool will be true, a NonZeroU32 will be 1, and so on. This is slow and probably not what you intended, but we did warn you that it was a bad idea to call this function still so...
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.
IIRC a big part of Google’s coding guidelines is also about making it easy for people not heavily invested in a specific language to contribute safely. So not necessarily a project size but rather an organizational concern.
They’d rather see it done the same way it would’ve been in any other similar language than with a language specific feature.
There are also portability concerns in mind given that projects like Chromium have to be easily portable across a vast amount of platforms (this shows with things like long long which is also on the list).
Some of it is historical reasons or portability more than anything else. Chrome is an old C++ project and evolved many of its own versions of functionality before standardization; and there's benefit to staying on its own implementations rather than switching.
Agreed. I also prefer conformity over sporadic use of new features going against an already set of standards in a codebase. it's overall less cognitive load on whoever is reading it imho.
Since Chromium stopped allowing manifest-v2 extensions, i.e. significantly crippled what extensions can do and made it impossible to use some key extensions like uBlock Origin, I've decided to avoid it.
Anyway, about these C++ conventions - to each software house its own I guess. I don't think banning exceptions altogether is appropriate; and I don't see the great benefit of using abseil (but feel free to convince me it's really that good.)
I spent a while on an open source project debugging some bizarre crashes. Cant remember exact detail but something like Someone was throwing an exception inside a destructor which had been triggered inside another exception. It was layers deep inside a massively templated 3rd party dependency library. so I like wound up parsing the string in the exception message and doing weird logic to make the program keep going since the exception wasnt actually a dire situation as far as the main program was concerned. So Exceptions can be fine in theory but I understand the idea that a ban can simplify a lot of things.
If nothing else Abseil gives you state-of-the-art hashmaps that run circles around the STL ones, which are slow pretty much by definition. The spec precludes the modern ways of implementing them.
> 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
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.
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 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.
For exception-less C++, you'd declare an operator new() that doesn't throw exceptions and just returns NULL on allocation failure along with a simple constructor and a followup explicitly-called init() method that does the real work which might fail and returns an error value on failure.
If you're planning on shutting down, what's the fundamental difference between throwing an exception, vs simply complaining loudly and calling exit() ..?
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.
> They're good for exceptional situations where foundamental, core assumptions are broken for some reason.
No, that's what assertions or contracts are for.
Most exceptions are supposed to be handled. The alternative to exceptions in C++ are error codes and `std::expected::. They are used for errors that are expected to happen (even if they may be exceptional). You just shouldn't use exceptions for control flow. (I'm looking at you, Python :)
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.
It's weird to me, as the former lead maintainer of this page for ten years or so, that this got submitted to both r/c++ and HN on the same day. Like... what's so exciting about it? Was there something on the page that caught someone's eye?
> We have something in-house designed for our use cases, use that instead of the standard lib equivalent
Yea, you encounter this a lot at companies with very old codebases. Don't use "chrono" because we have our own date/time types that were made before chrono even existed. Don't use standard library containers because we have our own containers that date back to before the STL was even stable.
I wonder how many of these (or the Google style guide rules) would make sense for a project starting today from a blank .cpp file. Probably not many of them.
The majority of things Chromium bans would still get banned in green-field use.
Some notable exceptions: we'd have allowed std::shared_ptr<T> and <chrono>. We might also have allowed <thread> and friends.
For the containers in particular this makes a lot of sense because the C++ stdlib containers are just not very good. Some of this is because C++ inherited types conceived as pedagogic tools. If you're teaching generic programming you might want both (single and double) extrusive linked list types for your explanation. But for a C++ programmer asking "Which of these do I want?" the answer is almost always neither.
The specification over-specifies std::unordered_map so that no good modern hash table type could implement this specification, but then under-specifies std::deque so that the MSVC std::deque is basically useless in practice. It requires (really, in the standard) that std::vector<bool> is a bitset, even though that makes no sense. It sometimes feels as though nobody on WG21 has any idea what they're doing, which is wild.
3 replies →
Don't use standard library containers because we have our own containers that date back to before the STL was even stable.
Flashback to last job. Wrote their own containers. Opaque.
You ask for an item from it, you get back a void pointer. It's a pointer to the item. You ask for the previous, or the next, and you give back that void pointer (because it then goes through the data to find that one again, to know from where you want the next or previous) and get a different void pointer. No random access. You had to start with the special function which would give you the first item and go from there.
They screwed up the end, or the beginning, depending on what you were doing, so you wouldn't get back a null pointer if there was no next or previous. You had to separately check for that.
It was called an iterator, but it wasn't an iterator; an iterator is something for iterating over containers, but it didn't have actual iterators either.
When I opened it up, inside there was an actual container. Templated, so you could choose the real inside container. The default was a QList (as in Qt 4.7.4). The million line codebase contained no other uses; it was always just the default. They took a QList, and wrapped it inside a machine that only dealt in void pointers and stripped away almost all functionality, safety and ability to use std::algorithm
I suspect but cannot prove that the person who did this was a heavy C programmer in the 1980s. I do not know but suspect that this person first encountered variable data type containers that did this sort of thing (a search for "generic linked list in C" gives some ideas, for example) and when they had to move on to C++, learned just enough C++ to recreate what they were used to. And then made it the fundamental container class in millions of lines of code.
3 replies →
> I wonder how many of these (or the Google style guide rules) would make sense for a project starting today from a blank .cpp file. Probably not many of them.
The STL makes you pay for ABI stability no matter if you want it or not. For some use cases this doesn't matter, and there are some "proven" parts of the STL that need a lot of justification for substitution, yada yada std::vector and std::string.
But it's not uncommon to see unordered_map substituted with, say, sparsehash or robin_map, and in C++ libraries creating interfaces that allow for API-compatible alternatives to use of the STL is considered polite, if not necessarily ubiquitous.
> I wonder how many of these (or the Google style guide rules) would make sense for a project starting today from a blank .cpp file. Probably not many of them.
That also depends on how standalone the project is. Self-contained projects may be better off with depending on standard library and popular third-party libraries, but if a project integrates with other internal components, it's better to stick to internal libraries, as they likely have workarounds and special functionality specific to the company and its development workflow.
I'd argue that the optimum was in long run to migrate to the standard version, that everyone (e.g. new employees) know. Replacing the usually particular (or even weird) way implemented own flavour.
I know, I know, long run does not exists in today's investor dominated scenarios. Code modernization is a fairytale. So far I seen no exception in my limited set of experiences (but with various codebases going back to the early 90's with patchy upgrades here and there, looking like and old coat fixed many many times with diverse size of patches of various materials and colour).
[flagged]
24 replies →
Somewhat notable is that `char8_t` is banned with very reasonable motivation that applies to most codebases:
> Use char and unprefixed character literals. Non-UTF-8 encodings are rare enough in Chromium that the value of distinguishing them at the type level is low, and char8_t* is not interconvertible with char* (what ~all Chromium, STL, and platform-specific APIs use), so using u8 prefixes would obligate us to insert casts everywhere. If you want to declare at a type level that a block of data is string-like and not an arbitrary binary blob, prefer std::string[_view] over char*.
`char8_t` is probably one of the more baffling blunders of the standards committee.
33 replies →
In a lot of places, they point out the std implementation is strictly inferior to theirs in some way, so its not always organizational inertia, it's that the C++ standard types could have been designed strictly better with no tradeoff.
> 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 bulk of the restrictions are justified as "Banned in the Google Style Guide."
In turn the Google Style Guide bans most of the features because they can't/won't refactor most of their legacy code to catch up with post C++0x.
So even then these guidelines are just a reflection of making sure things stay safe for upstream and downstream consumers of Google's largely unmaintained codebase.
I don't think that's an accurate representation. There are a few features like that, but the majority of things banned in the Google style guide are banned for safety, clarity, or performance concerns. Usually in such cases Google and/or Chromium have in-house replacements that choose different tradeoffs.
That's different from an inability to refactor.
Not an Googler, but my, probably way too much romanticized, understanding of Google was that they never ask you about specific tech because for everything there's an in-house version.
The problem is that too many people drank too much koolaid and trying to parrot everything to a letter without understanding the bigger picture.
The best example would be Kubernetes. Employed by many orgs that have 20 devs and 50 services.
> for everything there's an in-house version.
Reasonable summary. There's some massive NIH syndrome going on.
Another piece is that a lot of stuff that makes sense in the open source world does not make sense in the context of the giant google3 monorepo with however many billions of lines of code all in one pile.
<regex> [banned]
A good decision. I tried to use it once and realized that it can't even work with UTF-8 properly. It's a mystery for me how such flawed design was standardized at all.
Seeing the comments here talking about ancient codebases got me wistful for when Chromium was new and everything seemed possible.
That triggered a flash of feeling extremely old realizing we broke ground on this codebase 20 years ago this year!
There are yet more interesting docs in the parent directory :)
https://chromium.googlesource.com/chromium/src/+/main/styleg...
You almost never see a list of banned Java features (or even banned C# features). On the other hand any serious C++ development team is going to have a list of banned features. Java eliminated the features that you would want to ban.
This seems factually incorrect and ignorant of history. Java has tons of things which shouldn't be used. Serialization (use Jackson now, not the built-in stuff), date/time (there's an entirely different namespace so you don't accidentally use garbage classes), etc.
C# similarly has old warts that are discouraged now. .NET Framework is a great example (completely different from modern c#, which used to be called "dotnet core"). WPF and MAUI are also examples. Or when "dynamic" was used as a type escape hatch before the type system advanced to not need it. ASP being incompatible with ASP.NET, the list goes on.
They're just languages, there's no reason to pretend they're perfect.
> C# similarly has old warts that are discouraged now. .NET Framework is a great example (completely different from modern c#, which used to be called "dotnet core"). WPF and MAUI are also examples. Or when "dynamic" was used as a type escape hatch before the type system advanced to not need it. ASP being incompatible with ASP.NET, the list goes on.
Almost all of this is incorrect or comparing apples to oranges.
.net framework and .net core are runtime and standard library impl, not languages. C# is a language that can target either runtime or both. Framework is still supported today, and you can still use most modern C# language features in a project targeting it. WPF and Maui are both still supported and widely used. ASP predates .net - c# was never a supported language in it. ASP.net core has largely replaced ASP.net, but it's again a library and framework, not a language feature.
Dynamic in c# and the dlr are definitely not widely used because it's both difficult to use safely and doesn't fit well with the dominant paradigm of the language. If you're looking for STD lib warts binaryserializer would have been an excellent example.
1 reply →
C# can be used in both .NET Framework and modern .NET (ex-core). In fact, it is possible for a C# project to target both .NET Framework and .NET with the exact same code, or to target to .NET Standard, where the same .DLL file can be loaded by both. Since the old Framework is in maintenance mode, some modern language features will not work there, but you can still be productive with the old framework.
Dynamic is largely unnecessary, and it was unnecessary even when it was introduced.
ASP and ASP.NET are completely unrelated. ASP was designed to allow dynamic webpages to be written in VBScript (like CGI). This is not something you want to do in modern languages.
Those are libraries not language features.
4 replies →
In C#, you would normally implement rules like this with a custom Roslyn Analyzer or with https://github.com/dotnet/roslyn/blob/main/src/RoslynAnalyze.... It’s fair to say C# projects tend to have smaller denylists than mature C++ projects, but banned APIs definitely exist in mature C# projects.
I think Java has plenty of features that end up implicitly banned at least. e.g. you will really never see a `java.util.Vector` in any modern code base. No one `implements Serializable` anymore in practice. `Objects.equals()` and `Objects.hashCode()` get you through 99% of equals/hash code implementations. The list goes on.
I guess the difference is it's rarely "dangerous" or "hard to reason about" using the old features unlike what I see in the C++ list. Java replaces things with better things and momentum shifts behind them kind of naturally because the better things are objectively better.
> You almost never see a list of banned Java features ...
The instanceof[0] operator is typically banned from use in application code and often frowned upon in library implementations.
0 - https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.htm...
I've never heard of that being banned. It hasn't been banned anywhere i've written Java.
1 reply →
Never seen this being banned. Whats the reason?
I have, many companies have style guides enforced via Sonar and similar tools, what you don't see is everyone putting them on the Internet.
As a Java programmer I can only think of one thing:
Reflection - unless you really need to do something fancy almost certainly a very bad idea in normal application code.
Other than that it’s either just limiting yourself to a specific JVM version or telling people not to use old syntax/patterns that were replaced with better options long ago.
I would imagine most codebases, even in modern languages, tend to have a list of banned features. Typically you use a linter to catch these.
Unless you develop games in Unity, and have banned C# features like classes or LINQ (because they allocate on heap and Unity garbage collector is bad and make your game to micro freeze / stutter). Sure there are cases where classes are fine (singletons, pooling), but still...
Exceptions are banned, but an exception is made for Windows.
People that keep bringing this up always miss the rationable that Google code was written initially in a C style that isn't exception safe.
Key takeaway => "Things would probably be different if we had to do it all over again from scratch."
"On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.
Given that Google's existing code is not exception-tolerant, the costs of using exceptions are somewhat greater than the costs in a new project. The conversion process would be slow and error-prone. We don't believe that the available alternatives to exceptions, such as error codes and assertions, introduce a significant burden.
Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. Because we'd like to use our open-source projects at Google and it's difficult to do so if those projects use exceptions, we need to advise against exceptions in Google open-source projects as well. Things would probably be different if we had to do it all over again from scratch."
I'm quite happy to NOT have exceptions. I think they're a mistake as a language feature. What we need is first -class support for returning errors and propagating them, like what zig does. The next best thing are those RETURN macros that Google uses.
2 replies →
Both parts of your sentence refer to the Google style guide. This doc isn't the Google style guide. It's the Chromium modern c++ features doc. We don't talk about exceptions or platform-specific stuff (save a note on [[no_unique_address]]) in this doc.
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
1 reply →
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.
For most of the banned library features, the preferred alternative is listed right there in the notes. <filesystem> is one of the exceptions.
base/files
Gonna venture a guess and say probably https://www.chromium.org/developers, as that's where all the information for folks who actually need to know that kind of thing lives.
Modules are banned - they should have just copied D modules.
Good call on those u8"..." literals.
Source code should all be UTF-8 natively, letting you directly write UTF-8 text between quotes.
Exactly their rationale.
These literals are a solution in search of a problem ... which is real but has a much better solution.
This list is longer than the features in all of C I feel like at first glance. Wow that is overwhelming.
Is there a way to make this formal, like in the code, making the compiler complain when you try to use these features?
We have a linter that checks for most of them as a pre-upload hook.
I'm not a c++ user but i'm pretty sure you should be able to pull-off a macro to do that ; in c you could alias the lib for something that breaks + alert ; I don't know how I would integrate such additional compiler checks in rust for other kinds of rules however - it's interesting to think about
It’s a bit different, but WebKit uses Clangs static analysis.
It is relatively easy to check these things with static analyzers, if nothing else.
Kythe can be used for that
I'd curious about the banned Rust features. Surely, Rust has at lot fewer foot guns, but it isn't that there aren't any.
Rust has been better than C++ about marking where there's a foot gun and where practical just nerfing it. core::mem::uninitialized() is an example. In 2016 if you'd said "Initializing my Doodad is too expensive, what do I do?" you might be pointed at the (unsafe) core::mem::uninitialized() which "initializes" any variable, such as your Doodad but er, doesn't actually initialize it.
But that's a foot gun, there are niche cases where this crazy stunt actually is correct (ZSTs are one), but in general the compiler was in effect licensed to cause absolute mayhem because this isn't a Doodad at all, which isn't what you wanted. So, they did three things:
1. Made a new type wrapper for this purpose, MaybeUninit<Doodad> might not be a Doodad yet, so we can initialize it later and until then the compiler won't set everything on fire but it's the same shape as the Doodad.
2. Marked core::mem::uninitialized deprecated. If you use it now the compiler warns you that you shouldn't do that.
3. De-fanged it by, despite its name, scrawling the bit pattern 0x01 over all the memory. The compiler can see this has some particular value and for common types it's even valid, a bool will be true, a NonZeroU32 will be 1, and so on. This is slow and probably not what you intended, but we did warn you that it was a bad idea to call this function still so...
Heard of `#![forbid(unsafe_code)]` ?
It's that effectively enforcement of features that are banned?
1 reply →
#![deny(clippy::unwrap_used)]
I doubt unsafe would be blatantly banned. I was more thinking of things like glob imports.
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.
IIRC a big part of Google’s coding guidelines is also about making it easy for people not heavily invested in a specific language to contribute safely. So not necessarily a project size but rather an organizational concern.
They’d rather see it done the same way it would’ve been in any other similar language than with a language specific feature.
There are also portability concerns in mind given that projects like Chromium have to be easily portable across a vast amount of platforms (this shows with things like long long which is also on the list).
Go is an extremely cynical language in this regard.
Some of it is historical reasons or portability more than anything else. Chrome is an old C++ project and evolved many of its own versions of functionality before standardization; and there's benefit to staying on its own implementations rather than switching.
Agreed. I also prefer conformity over sporadic use of new features going against an already set of standards in a codebase. it's overall less cognitive load on whoever is reading it imho.
Rust is too complicated!!11 Ooops wrong thread.
Since Chromium stopped allowing manifest-v2 extensions, i.e. significantly crippled what extensions can do and made it impossible to use some key extensions like uBlock Origin, I've decided to avoid it.
Anyway, about these C++ conventions - to each software house its own I guess. I don't think banning exceptions altogether is appropriate; and I don't see the great benefit of using abseil (but feel free to convince me it's really that good.)
I spent a while on an open source project debugging some bizarre crashes. Cant remember exact detail but something like Someone was throwing an exception inside a destructor which had been triggered inside another exception. It was layers deep inside a massively templated 3rd party dependency library. so I like wound up parsing the string in the exception message and doing weird logic to make the program keep going since the exception wasnt actually a dire situation as far as the main program was concerned. So Exceptions can be fine in theory but I understand the idea that a ban can simplify a lot of things.
If nothing else Abseil gives you state-of-the-art hashmaps that run circles around the STL ones, which are slow pretty much by definition. The spec precludes the modern ways of implementing them.
Indeed, the standard library maps are quite slow, and I often point that out to people:
https://stackoverflow.com/a/42588384/1593077
But you can and should use non-std state-of-the-art hashmaps without living in the world of abseil.
1 reply →
C++ itself should be forever banned
Ok. You can stop using anything written in C++.
How would you implement a C++ ban in Chromium?
It's remarkable to me how many codebases ban exceptions and yet, somehow, people still insist they're good.
> 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.
5 replies →
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.
19 replies →
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?
6 replies →
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.
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.
For exception-less C++, you'd declare an operator new() that doesn't throw exceptions and just returns NULL on allocation failure along with a simple constructor and a followup explicitly-called init() method that does the real work which might fail and returns an error value on failure.
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.
If you're planning on shutting down, what's the fundamental difference between throwing an exception, vs simply complaining loudly and calling exit() ..?
5 replies →
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.
> They're good for exceptional situations where foundamental, core assumptions are broken for some reason.
No, that's what assertions or contracts are for.
Most exceptions are supposed to be handled. The alternative to exceptions in C++ are error codes and `std::expected::. They are used for errors that are expected to happen (even if they may be exceptional). You just shouldn't use exceptions for control flow. (I'm looking at you, Python :)
I use asserts for this purpose.
Looking at this ban list, they've removed everything from C++ that makes it fun. Come on people, who doesn't love a little std::function?!?
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
We have base::Callback for when you'd reach for std::function, which provides superior safety.