11 ms·

Banned C++ features in Chromium

• Night_Thastus 9mo ago
  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.
  • ryandrake 9mo ago
    > 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.
    • mtklein 9mo ago
      [flagged]
      • acdha 9mo ago
        Look, I even share your language preference but this is still unnecessary.
        • galangalalgol 9mo ago
          Are there really any good reasons to start a brand new project in c++ though? No one who can write modern c++ has any trouble with rust in my experience, and all the other common options are even quicker to pick up. Creating bindings isn't hard anymore if your niche library doesn't have any yet. Syntactic preference I guess, but neither c++ or rust are generally considered elegant or aesthetic choices.
          • BearOso 9mo ago
            Rust becomes a significant burden if you need a GUI or hardware-accelerated graphics.
            • jenadine 9mo ago
              C++ isn't much better for GUI.
              • johnny22 9mo ago
                I assume most of them are just grabbing qt
              • pjmlp 9mo ago
                C++ was the GUI king during the 1990's, and none of the Rust toolkits is half as good as the surviving frameworks, like C++ Builder, Qt, wxWidgets, heck even MFC has better tooling.
                • LexiMax 9mo ago
                  > wxWidgets I'll trade you wxWidgets for FLTK. Trying to defer to native widget rendering per platform was a mistake, and every time I've touched wxWidgets in the past decade and a half I've regretted it. FLTK on the other hand is ugly as sin, but I've found it reliable enough to not act in surprising ways, and it's also small enough to where you can vendor it and build it alongside your program.
          • CamperBob2 9mo ago
            (Shrug) If I want Rust, I'll feed my C++ to an LLM and tell it to port it to Rust. Since we've been assured that Rust magically fixes everything that's wrong, bad, or unsafe about C++, this seems like a sound approach.
            • galangalalgol 9mo ago
              We probably aren't that far off actually. Even taking asm with no symbols back into rust works well. You have truth, just have the agent repeat until the asm matches. Doesn't work on giant codebases, but on a few functions it absolutely does. And while the llm may get the algorithm wrong, the type system does seem to help it generate useful code in rust for a starting place v
    • LexiMax 9mo ago
      > 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.
    • mihaaly 9mo ago
      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).
      • pkasting 9mo ago
        When I led C++ style/modernization for Chromium, I made this argument frequently: we should prefer the stdlib version of something unless we have reason not to, because incoming engineers will know it, you can find advice on the internet about it, clang-tidy passes will be written for it, and it will receive optimizations and maintenance your team doesn't have to pay for. There are cases, however, when the migration costs are significant enough that even those benefits aren't really enough. Migrating our date/time stuff to <chrono> seemed like one of those.
    • EliRivers 9mo ago
      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.
      • cracki 9mo ago
        time to refactor the code base so this tumor can be deleted?
        • EliRivers 9mo ago
          The complete refactor, bringing it forwards from VS2008 to VS2022, and from a home-built, source-code edited Qt 4.7.4 to Qt 6.something, took about two years from start to finish.
          • 9mo ago
    • TeMPOraL 9mo ago
      > 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.
    • tialaramex 9mo ago
      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.
      • menaerus 9mo ago
        [flagged]
      • direwolf20 9mo ago
        Linked lists used to be more efficient than dynamic arrays — 40 years ago, before processors had caches.
        • dahart 9mo ago
          Intrusive linked lists still firmly have a place in modern code, for reasons other than performance. I don’t know many good reasons for extrusive linked lists, even before caches. There might be a few, but a dynamic array is (and has always been?) usually preferable to an extrusive list.
          • mshockwave 9mo ago
            > I don’t know many good reasons for extrusive linked lists for one, its iterator won't be invalidated
            • dahart 9mo ago
              That depends on which array & extrusive linked list classes you’re talking about. Let me put it another way: in three decades of professional coding in scientific computing, video games, film vfx, web programming, and GPU driver and hardware development, I’ve never had to reach for an extrusive linked list for work. I’ve only ever used them for learning, teaching, and toy projects.
    • pkasting 9mo ago
      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.
  • vitaut 9mo ago
    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*.
    • ChrisSD 9mo ago
      `char8_t` is probably one of the more baffling blunders of the standards committee.
      • jjmarr 9mo ago
        there is no guarantee `char` is 8 bits, nor that it represents text, or even a particular encoding. If your codebase has those guarantees, go ahead and use it.
        • dataflow 9mo ago
          How many non-8-bit-char platforms are there with char8_t support, and how many do we expect in the future?
          • dspwizard 9mo ago
            TI C2000 is one example
            • dataflow 9mo ago
              Thank you. I assume you're correct, though for some reason I can't find references claiming C++20 being supported with some cursory searches.
          • RobotToaster 9mo ago
  • zeroq 9mo ago
    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.
    • dmoy 9mo ago
      > 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.
  • torginus 9mo ago
    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.
  • locknitpicker 9mo ago
    > 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.
    • pkasting 9mo ago
      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.
  • pkasting 9mo ago
    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?
• dfajgljsldkjag 9mo ago
  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.
  • trinix912 9mo ago
    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).
    • jonstewart 9mo ago
      Go is an extremely cynical language in this regard.
  • loeg 9mo ago
    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.
  • diabllicseagull 9mo ago
    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.
• ddtaylor 9mo ago
  Exceptions are banned, but an exception is made for Windows.
  • refulgentis 9mo ago
    grep'd "exception" and "Windows", tl;dr only Windows reference is for `[[no_unique_address]]`. Therefore I am probably missing a joke :)
    • jesse__ 9mo ago
      Might be referring to SEH ..? Just a wild guess
      • refulgentis 9mo ago
        Ah, found it: in the style guide linked from this article. https://google.github.io/styleguide/cppguide.html#Exceptions https://google.github.io/styleguide/cppguide.html#Exceptions
  • pjmlp 9mo ago
    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."
• jesse__ 9mo ago
  It's remarkable to me how many codebases ban exceptions and yet, somehow, people still insist they're good.
  • tester756 9mo ago
    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.
    • dijit 9mo ago
      I use asserts for this purpose.
    • jesse__ 9mo ago
      If you're planning on shutting down, what's the fundamental difference between throwing an exception, vs simply complaining loudly and calling exit() ..?
      • trinix912 9mo ago
        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.
        • PhilipRoman 9mo ago
          Your process can crash or be killed at any moment anyway. Depending on in-band cleanup is not reliable.
          • nomel 9mo ago
            Sure, but there are many cases where you don't have to halt because you can cleanup and carry on.
• WalterBright 9mo ago
  Modules are banned - they should have just copied D modules.
  • random_mutex 9mo ago
    Because of compiler support
    • WalterBright 9mo ago
      Which suggests (and I don't know this for a fact) that C++ modules are difficult to implement. D's are easy. I would have made C++ modules be a slightly modified namespace.
      • pkasting 9mo ago
        C++ module implementation is a story with a lot of drama, if you ever want to read up on it. The short summary, though, is that no toolchain yet has a bulletproof implementation, though everybody at least has enough to let people kick the tires a bit.
• dnmc 9mo ago
  There are yet more interesting docs in the parent directory :) https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++ https://chromium.googlesource.com/chromium/src/+/main/styleg...
• amelius 9mo ago
  Is there a way to make this formal, like in the code, making the compiler complain when you try to use these features?
  • loeg 9mo ago
    It is relatively easy to check these things with static analyzers, if nothing else.
  • 6r17 9mo ago
    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
  • TingPing 9mo ago
    It’s a bit different, but WebKit uses Clangs static analysis.
  • mkoubaa 9mo ago
    Kythe can be used for that
  • pkasting 9mo ago
    We have a linter that checks for most of them as a pre-upload hook.
• Tempest1981 9mo ago
  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.
  • TheRealPomax 9mo ago
    Gonna venture a guess and say probably https://www.chromium.org/developers https://www.chromium.org/developers, as that's where all the information for folks who actually need to know that kind of thing lives.
    • deleted 9mo ago
      [deleted]
  • jeffbee 9mo ago
    base/files
  • comex 9mo ago
    For most of the banned library features, the preferred alternative is listed right there in the notes. <filesystem> is one of the exceptions.
    • pkasting 9mo ago
      Yeah, maintainers would certainly +1 a CL that added a note about the parts of //base to use instead. Trivial oversight.
• grougnax 9mo ago
  C++ itself should be forever banned
  • Expurple 9mo ago
    How would you implement a C++ ban in Chromium?
  • j16sdiz 9mo ago
    Ok. You can stop using anything written in C++.
• lateforwork 9mo ago
  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.
  • nilamo 9mo ago
    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.
    • lateforwork 9mo ago
      Those are libraries not language features.
      • plorkyeran 9mo ago
        So is nearly all of this list.
        • lateforwork 9mo ago
          There are clearly demarcated language features sections and library sections. That definitely makes sense for C++, it is a poorly designed language and you definitely have to know what features to avoid.
          • drysine 9mo ago
            > C++, it is a poorly designed language Unlike C# that has both delegates and lambdas, for example. Also finalizers and IDisposable.
• einpoklum 9mo ago
  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.)
  • jsheard 9mo ago
    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.
    • einpoklum 9mo ago
      Indeed, the standard library maps are quite slow, and I often point that out to people: https://stackoverflow.com/a/42588384/1593077 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.
      • pkasting 9mo ago
        Sure; you can roll your own, or you can use one of the many other libraries that provide alternatives. There are obvious downsides to the former, and the latter is basically equivalent to using the Abseil ones in terms of practical tradeoffs. Chromium uses hundreds of other open source libraries. Is there something about Abseil specifically that sticks in your craw?
  • don-bright 9mo ago
    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.
• weinzierl 9mo ago
  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.
  • jtrueb 9mo ago
    Heard of `#![forbid(unsafe_code)]` ?
    • jenadine 9mo ago
      #![deny(clippy::unwrap_used)]
    • weinzierl 9mo ago
      I doubt unsafe would be blatantly banned. I was more thinking of things like glob imports.
    • bulbar 9mo ago
      It's that effectively enforcement of features that are banned?
      • tialaramex 9mo ago
        Rust's compiler has six what it calls "lint levels" two of which can't be overridden by compiler flags, these handle all of its diagnostics and are also commonly used by linters like clippy. Allow and Expect are levels where it's OK that a diagnostic happened, but with Expect if the diagnostic expected was not found then we get another diagnostic telling us that our expectation wasn't fulfilled. Warn and Force-Warn are levels where we get a warning but compilation results in an executable anyway. Force-warn is a level where you can't tell the compiler not to emit this warning. Deny and Forbid are levels where the diagnostic is reported and compilation fails, so we do not get an executable. Forbid, like Force-warn cannot be overriden with compiler flags.
  • deleted 9mo ago
    [deleted]
  • 9mo ago
• bengoodger 9mo ago
  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!
• kazinator 9mo ago
  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.
• bfrog 9mo ago
  This list is longer than the features in all of C I feel like at first glance. Wow that is overwhelming.
  • rappatic 9mo ago
    Yeah lord C++ is a gigantic language
• nixosbestos 9mo ago
  Rust is too complicated!!11 Ooops wrong thread.
• Panzerschrek 9mo ago
  <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.
  • buckle8017 9mo ago
    All modern regex libraries have a Unicode mode. Also regex predates utf8.
    • Sharlin 9mo ago
      But <regex> definitely does not predate utf-8.
• GnarfGnarf 9mo ago
  I thought User-Defined Literals were a great idea until I saw all the pitfalls listed in the Google style document. Dangerous indeed.
  • pkasting 9mo ago
    FWIW, I still think the Google Style Guide banning UDLs entirely is too harsh. I think they should be used sparingly, but there are cases where they make sense. In Chromium's UI code, we have a lot of APIs that deal with coordinates, which may be in either px or dp. And we have a lot of code that needs to hardcode various constants, e.g. layout values for different dialogs. IMO, it's sane to have UDL support here, e.g. `20_px` (at least if we had separate types to represent these two things, which we don't... don't get me started).
    • GnarfGnarf 9mo ago
      Agree. I love UDLs, use them in my code for improved legibility. I hadn’t realized how badly you can screw up if you don’t define all the operators correctly.