hckrnws

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.

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

Linked lists used to be more efficient than dynamic arrays — 40 years ago, before processors had caches.

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.

> I don’t know many good reasons for extrusive linked lists

for one, its iterator won't be invalidated

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.

I haven't benchmarked them myself yet, but the C++23 flat map containers are supposed to finally have fixed this. Chrome lists them as TBD: https://chromium.googlesource.com/chromium/src/+/main/styleg... .

When you say "fixed this" which "this" do you think they fixed? Are you imagining this is a hash table? It's not

It's an adaptor which will use two other containers (typically std::vector) to manage the sorted keys and their associated values. The keys are sorted and their values are stored in the corresponding position in their own separate std::vector. If you already have sorted data or close enough then this type can be created almost for free yet it has similar affordances to std::map - if you don't it's likely you will find the performance unacceptable.

[flagged]

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.

time to refactor the code base so this tumor can be deleted?

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.

> home-built, source-code edited Qt 4.7.4

That's scarier than the containter craziness you mention

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

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.

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

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.

[flagged]

Look, I even share your language preference but this is still unnecessary.

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.

Because "brand new" doesn't mean devoid of context. Within your domain, there will still be common libraries, interfaces, and tools.

C++ is very flexible, with a lot of very mature tooling and incredibly broad platform support. If you're writing some web server to run on the hardware of your choosing, then sure, that doesn't matter. But if you're writing something deeply integrated with platform/OS interfaces, or graphics, or needs to support some less common platforms, then C++ is often your only practical option for combining expressiveness and performance.

This is the sort of info I was trolling for, but what are those platforms and os? Targets llvm doesn't handle yeah c++ makes sense, or c. A sibling mentions xcode, which makes sense. Graphics seems questionable, vulkan support is fine. Windows support has seemed finetoo, the same gui has worked as what we wrote for Linux.

Dependencies. There are billions of lines of C++ out there that have been optimized and production hardened over decades that you might want to reuse. Rust lang interoperability with anything but C sucks in practice.

Unreal, Godot, CryEngine, DirectX, PlayStation, Switch, XBox, CUDA, SYSCL, LLVM, GCC, V8,...

Maybe, maybe not. But either way it's just plain rude to charge into a C++ thread to drop a comment saying how the language sucks and you should use (insert other language) instead.

Yes, there are plenty of domains where Rust has zero ecosystem.

Not to mention that Rust advocates keep forgetting their compiler is partially written in C++ (LLVM/GCC).

Rust becomes a significant burden if you need a GUI or hardware-accelerated graphics.

C++ isn't much better for GUI.

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.

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

I assume most of them are just grabbing qt

In addition to other reasons given: If you have a team of C++ developers, let them use the language they know best.

Yes. If you're targeting Apple platforms and want to allow clients to use your product in Xcode (the common case) or even need Swift/ObjC interop yourself, using rust or anything not explicitly supported by Apple and Xcode is just too fiddly.

Why not pick swift in this situation over c++?

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

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

Yeah, but then just let the agent generate proper C++ code, contrary to an human it doesn't forget about best practices, or how ownership is supposed to be handled.

Except the llm forgets about that in rust too, then the agent looks at the ownership errors from the previous iteration and fixes them.

First it needs to have a Rust ecosystem available, e.g. CUDA, SYSCL, HFT, HPC,...

Maybe it could be used to remove Rust dependency on C++ infrastructure (LLVM/GCC), and bring Cranelift up to speed.

You missed the other take, with AI assisted coding, you can stay in C++, as it will take care everything is coded with enough care.

Or why bother with Rust, when the LLM gets to generate C++ code with best practices.

While I like Rust, I think AI as the next abstraction step in programming has kind of taken its relevance away, when computer assisted programming is part of the workflow.

Strange. I wouldn’t trust the output of a coding agent and I would want stronger review of its output. If it passes a strict compiler that gives me more confidence than if it passed a lax one.

But sure, if you trust it to have written C++ to a higher standard than the experts, then go for it.

So not into the vibe coding hype taking over all our jobs?

It is what it is, I accept that’s where the industry is heading.

But if I have to produce reams of code I’d much rather have it be reviewed by rustc than clang. rustc may take longer to satisfy, but it’ll be worth it because I won’t be responsible for horrors in production.

You’re happy to be responsible for buffer overflows written by an LLM? I’m not, which is why I prefer a language where it’s not possible.

It is definitely possible, only not as easy.

Even reviewing human written C++ is difficult. Android has had 20 years to figure it out and they couldn’t find a way to reduce the number of vulnerabilities they introduced in carefully crafted C++ code. I shudder to think how many more they would have introduced if they had vibe coded it.

Yeah, good point, I don't know how I missed that possibility.

/s of course... for now, but not for long.

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.

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.

> there is no guarantee `char` is 8 bits, nor that it represents text, or even a particular encoding.

True, but sizeof(char) is defined to be 1. In section 7.6.2.5:

"The result of sizeof applied to any of the narrow character types is 1"

In fact, char and associated types are the only types in the standard where the size is not implementation-defined.

So the only way that a C++ implementation can conform to the standard and have a char type that is not 8 bits is if the size of a byte is not 8 bits. There are historical systems that meet that constraint but no modern systems that I am aware of.

[1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n49...

That would be any CPU with word-addressing only. Which, granted, is very exotic today, but they do still exist: https://www.analog.com/en/products/adsp1802.html

Don't some modern DSPs still have 32bit as minimum addressable memory? Or is it a thing of the past?

If you're on such a system, and you write code that uses char, then perhaps you deserve whatever mess that causes you.

char8_t also isn't guaranteed to be 8-bits, because sizeof(char) == 1 and sizeof(char8_t) >= 1. On a platform where char is 16 bits, char8_t will be 16 bits as well

The cpp standard explicitly says that it has the same size, typed, signedness and alignment as unsigned char, but its a distinct type. So its pretty useless, and badly named

Wouldn't it be rather the case that char8_t just wouldn't exist on that platform? At least that's the case with the uintN_t types, they are just not available everywhere. If you want something that is always available you need to use uintN_least_t or uintN_fast_t.

wtf

It is pretty consistent. It is part of the C Standard and a feature meant to make string handling better, it would be crazy if it wasn't a complete clusterfuck.

There's no guarantee char8_t is 8 bits either, it's only guaranteed to be at least 8 bits.

> There's no guarantee char8_t is 8 bits either, it's only guaranteed to be at least 8 bits.

Have you read the standard? It says: "The result of sizeof applied to any of the narrow character types is 1." Here, "narrow character types" means char and char8_t. So technically they aren't guaranteed to be 8 bits, but they are guaranteed to be one byte.

Yes, but the byte is not guaranteed to be 8 bits, because on many ancient computers it wasn't.

The poster to whom you have replied has read correctly the standard.

What platforms have char8_t as more than 8 bits?

Well platforms with CHAR_BIT != 8. In c and c++ char and there for byte is atleast 8 bytes not 8 bytes. POSIX does force CHAR_BIT == 8. I think only place is in embeded and that to some DSPs or ASICs like device. So in practice most code will break on those platforms and they are very rare. But they are still technically supported by c and c++ std. Similarly how c still suported non 2's complement arch till 2023.

That's where the standard should come in and say something like "starting with C++26 char is always 1 byte and signed. std::string is always UTF-8" Done, fixed unicode in C++.

But instead we get this mess. I guess it's because there's too much Microsoft in the standard and they are the only ones not having UTF-8 everywhere in Windows yet.

char is always 1 byte. What it's not always is 1 octet.

you're right. What I meant was that it should always be 8 bit, too.

std::string is not UTF-8 and can't be made UTF-8. It's encoding agnostic, its API is in terms of bytes not codepoints.

Of course it can be made UTF-8. Just add a codepoints_size() method and other helpers.

But it isn't really needed anyway: I'm using it for UTF-8 (with helper functions for the 1% cases where I need codepoints) and it works fine. But starting with C++20 it's starting to get annoying because I have to reinterpret_cast to the useless u8 versions.

First, because of existing constraints like mutability though direct buffer access, a hypothetical codepoints_size() would require recomputation each time which would be prohibitively expensive, in particular because std::string is virtually unbounded.

Second, there is also no way to be able to guarantee that a string encodes valid UTF-8, it could just be whatever.

You can still just use std::string to store valid encoded UTF-8, you just have to be a little bit careful. And functions like codepoints_size() are pretty fringe -- unless you're not doing specialized Unicode transformations, it's more typical to just treat strings as opaque byte slices in a typical C++ application.

Perfect is the enemy of good. Or do you think the current mess is better?

std::string _cannot_ be made "always UTF-8". Is that really so contentious?

You can still use it to contain UTF-8 data. It is commonly done.

I never said always. Just add some new methods for which it has to be UTF-8. All current functions that need an encoding (e.g. text IO) also switch to UTF-8. Of course you could still save arbitrary binary data in it.

> That's where the standard should come in and say something like "starting with C++26 char is always 1 byte and signed. std::string is always UTF-8" Done, fixed unicode in C++.

> I never said always

Yes you totally did. And regarding "add some new methods for which it has to be UTF-8", there is no need at all to add UTF-8 methods to std::string. It would be a bad idea. UTF-8 is not bound to a particular type (or C++ type). It works on _any_ byte sequence.

You're right, sorry.

Good point, so maybe the standard should just add some functions that take std::string_view. Definitely not add a whole new class like std::u8string ...

How many non-8-bit-char platforms are there with char8_t support, and how many do we expect in the future?

Mostly DSPs

Is there a single esoteric DSP in active use that supports C++20? This is the umpteenth time I've seen DSP's brought up in casual conversations about C/C++ standards, so I did a little digging:

Texas Instruments' compiler seems to be celebrating C++14 support: https://www.ti.com/tool/C6000-CGT

CrossCore Embedded Studio apparently supports C++11 if you pass a switch in requesting it, though this FAQ answer suggests the underlying standard library is still C++03: https://ez.analog.com/dsp/software-and-development-tools/cce...

Everything I've found CodeWarrior related suggests that it is C++03-only: https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/...

Aside from that, from what I can tell, those esoteric architectures are being phased out in lieu of running DSP workloads on Cortex-M, which is just ARM.

I'd love it if someone who was more familiar with DSP workloads would chime in, but it really does seem that trying to be the language for all possible and potential architectures might not be the right play for C++ in 202x.

Besides, it's not like those old standards or compilers are going anywhere.

Cadence DSPs have C++17 compatible compiler and will be c++20 soon, new CEVA cores also (both are are clang based). TI C7x is still C++14 (C6000 is ancient core, yet still got c++14 support as you mentioned). AFIR Cadence ASIP generator will give you C++17 toolchain and c++20 is on roadmap, but not 100% sure.

But for those devices you use limited subset of language features and you would be better of not linking c++ stdlib and even c stdlib at all (so junior developers don't have space for doing stupid things ;))

Green Hills Software's compiler supports more recent versions of C++ (it uses the EDG frontend) and targets some DSPs.

Back when I worked in the embedded space, chips like ZSP were around that used 16-bit bytes. I am twenty years out of date on that space though.

How common is it to use Green Hills compilers for those DSP targets? I was under the impression that their bread was buttered by more-familiar-looking embedded targets, and more recently ARM Cortex.

Dunno! My last project there was to add support for one of the TI DSPs, but as I said, that's decades past now.

Anyway, I think there are two takeaways:

1. There probably do exist non-8-bit-byte architectures targeted by compilers that provide support for at-least-somewhat-recent C++ versions

2. Such cases are certainly rare

Where that leaves things, in terms of what the C++ standard should specify, I don't know. IIRC JF Bastien or one of the other Apple folks that's driven things like "twos complement is the only integer representation C++ supports" tried to push for "bytes are 8 bits" and got shot down?

> but it really does seem that trying to be the language for all possible and potential architectures might not be the right play for C++ in 202x.

Portability was always a selling point of C++. I'd personaly advise those who find it uncomfortable, to choose a different PL, perhaps Rust.

> Portability was always a selling point of C++.

Judging by the lack of modern C++ in these crufty embedded compilers, maybe modern C++ is throwing too much good effort after bad. C++03 isn't going away, and it's not like these compilers always stuck to the standard anyway in terms of runtime type information, exceptions, and full template support.

Besides, I would argue that the selling point of C++ wasn't portability per se, but the fact that it was largely compatible with existing C codebases. It was embrace, extend, extinguish in language form.

> Judging by the lack of modern C++ in these crufty embedded compilers,

Being conservative with features and deliberately not implementing them are two different thing. Some embedded compilers go through certification, to be allowed to be used producing mission critical software. Chasing features is prohibitively expensive, for no obvious benefit. I'd bet in 2030s most embedded compiler would support C++ 14 or even 17. Good enough for me.

> Being conservative with features and deliberately not implementing them are two different thing.

There is no version of the C++ standard that lacks features like exceptions, RTTI, and fully functional templates.

If the compiler isn't implementing all of a particular standard then it's not standard C++. If an implementation has no interest in standard C++, why give those implementations a seat at the table in the first place? Those implementations can continue on with their C++ fork without mandating requirements to anyone else.

> If the compiler isn't implementing all of a particular standard then it's not standard C++.

C++ have historically been driven by practicalities, and violated standards on regular basis, when it deemed useful.

> Those implementations can continue on with their C++ fork without mandating requirements to anyone else.

Then they will diverge too much, like it happened with countless number of other languages, like Lisp.

> Then they will diverge too much, like it happened with countless number of other languages, like Lisp.

Forgive me if I am unconvinced that the existence of DSP-friendly dialects of C++ will cause the kinds of language fracturing that befell Lisp.

DSP workloads are relatively rare compared to the other kinds of workloads C++ is tasked with, and even in those instances a lot of DSP work is starting to be done on more traditional architectures like ARM Cortex-M.

Non-8-bit-char DSPs would have char8_t support? Definitely not something I expected, links would be cool.

Why not? except it is same as `unsigned char` and can be larger than 8 bit

ISO/IEC 9899:2024 section 7.30

> char8_t which is an unsigned integer type used for 8-bit characters and is the same type as unsigned char;

> Why not?

Because "it supports Unicode" is not an expected use case for a non-8-bit DSP?

Do you have a link to a single one that does support it?

The exact size types are never present on platforms that don't support them.

TI C2000 is one example

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.

char on linux arm is unsigned, makes for fun surprises when you only ever dealt with x86 and assumed char to be signed everywhere.

This bit us in Chromium. We at least discussed forcing the compiler to use unsigned char on all platforms; I don't recall if that actually happened.

I recall that google3 switched to -funsigned-char for x86-64 a long time ago.

A cursory Chromium code search does not find anything outside third_party/ forcing either signed or unsigned char.

I suspect if I dug into the archives, I'd find a discussion on cxx@ with some comments about how doing this would result in some esoteric risk. If I was still on the Chrome team I'd go looking and see if it made sense to reraise the issue now; I know we had at least one stable branch security bug this caused.

Related: in C at least (C++ standards are tl;dr), type names like `int32_t` are not required to exist. Most uses, in portable code, should be `int_least32_t`, which is required.

Isn't the real reason to use char8_t over char that it that char8_t* are subject to the same strict aliasing rules as all other non-char primitive types? (i.e., the compiler doesn't have to worry that a char8_t* could point to any random piece of memory like it would for char*?).

At least in Chromium that wouldn't help us, because we disable strict aliasing (and have to, as there are at least a few core places where we violate it and porting to an alternative looks challenging; some of our core string-handling APIs that presume that wchar_t* and char16_t* are actually interconvertible on Windows, for example, would have to begin memcpying, which rules out certain API shapes and adds a perf cost to the rest).

The main effect of this is that some of the conversions between char and char8_t are inefficient.

> using u8 prefixes would obligate us to insert casts everywhere.

Unfortunately, casting a char8_t* to char* (and then accessing the data through the char* pointer) is undefined behavior.

Yes, reading the actual data would still be UB. Hopefully will be fixed in C++29: https://github.com/cplusplus/papers/issues/592

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?

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.

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!

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

All modern regex libraries have a Unicode mode.

Also regex predates utf8.

But <regex> definitely does not predate utf-8.

There are yet more interesting docs in the parent directory :)

https://chromium.googlesource.com/chromium/src/+/main/styleg...

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.

Isn't that equivalent to exceptions but more verbose and slower?

"first-class support for returning errors and propagating them" certainly sounds like exceptions! In fact, the compiler can even emit special tables that let the runtime completely skip over stack frames that don't need to do any cleanup during that propagation step!

Some languages have even innovated new kinds of exceptions that you can throw but that you are admonished should almost certainly never be caught.

Unfortunately even this is also better for tool support, a problem that using a bunch of macros solves. It's cool and good when a variable gets declared inside the guts of some macro expansion (and--critically--escapes those guts).

Its not the same. You have to explicitly declare the errors and if you want to ignore/propagate them, you have to do so explicitly as well.

You cant invoke a function and pretend it'll never fail.

Also, try/catch with long try blocks and a the error handling at the very end is just bad. Which of the statements in the try is throwing? Even multiple perhaps? Each should be handled individually and immediately

Deliberately more verbose. Not sure how it'd be slower. And only a tiny bit more verbose if the language has nice keywords/syntax for you to use. The point is you want to be explicit when you're choosing to ignore an error.

Having to support legacy code is a bummer. /s

Zig remains to be seen how market relevant it turns out to be.

Ya, we don't know yet. Still sitting on zig but I like what I see so far.

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

Ah, found it: in the style guide linked from this article. https://google.github.io/styleguide/cppguide.html#Exceptions

This list is longer than the features in all of C I feel like at first glance. Wow that is overwhelming.

Yeah lord C++ is a gigantic language

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.

Yeah, maintainers would certainly +1 a CL that added a note about the parts of //base to use instead. Trivial oversight.

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.

base/files

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.

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.

Modules are banned - they should have just copied D modules.

Because of compiler support

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.

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.

I thought User-Defined Literals were a great idea until I saw all the pitfalls listed in the Google style document. Dangerous indeed.

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

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.

Is there a way to make this formal, like in the code, making the compiler complain when you try to use these features?

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

We have a linter that checks for most of them as a pre-upload hook.

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?

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.

#![deny(clippy::unwrap_used)]

I doubt unsafe would be blatantly banned. I was more thinking of things like glob imports.

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.

Dynamic is still nice when you’re dealing with unknown data imo. More hygienic to read than dictionary access through string keys for example.

I use it when deserializing unknown message types.

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.

So is nearly all of this list.

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.

> C++, it is a poorly designed language

Unlike C# that has both delegates and lambdas, for example. Also finalizers and IDisposable.

dynamic is a language feature

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.

Similarly I never been in a company that outright banned c++ language of library features[1]. Turns out that different companies are different.

[1] I guess you would get some push back at review time if you used auto_ptr.

> I've never heard of that being banned. It hasn't been banned anywhere i've written Java.

Once code such as the below is rejected in a code review, the next version often submitted is an "if-else-if" ladder using `instanceof` (which is effectively the same thing).

  TheReturnType r = null;

  try {
    DomainType1 instance = (DomainType1)obj;

    r = ...
    }
    catch (ClassCastException ex) {}

  if (r == null)
    try {
      DomainType2 instance = (DomainType2)obj;

      r = ...
      }
      catch (ClassCastException ex) {}

  if (r == null)
    try {
      DomainType3 instance = (DomainType3)obj;

      r = ...
      }
      catch (ClassCastException ex) {}

  ...

Never seen this being banned. Whats the reason?

If you have to ask an object what its type is, you're probably about to cast it, and these are operations that the language doesn't enforce that you do together (and so the habit of casting can lead to the habit of casting without the check...). There are times when it's appropriate but generally if you have to ask what type an object is, your code is already starting to smell (because typically dispatching on type is handled by polymorphism, not be the programmer manually implementing it).

>> The instanceof[0] operator is typically banned from use in application code and often frowned upon in library implementations.

> Never seen this being banned. Whats the reason?

Its usage encodes a priori assumptions of what a super-type could be, often expressed in an "if-else-if tree", thus making the logic doing so needlessly brittle and difficult to maintain.

Library logic sometimes needs to use this construct (I'd argue those abstractions need to be rethought however), but an application which does exhibits a failure in domain modelling IMHO.

It can be a code smell, but there are legitimate uses. This is not something that I would ever "ban".

Over-eager code analyser tools are themselves a "smell", in that you either justifiably or unjustifiably don't trust your developers, trying to make up for their real or perceived deficits with a rather dumb tool. That never goes well in my experience.

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 have, many companies have style guides enforced via Sonar and similar tools, what you don't see is everyone putting them on the Internet.

Java has so few features that there's not much to ban. Nevertheless Java definitely has language features (in addition to deprecated library APIs, which are many) that aren't recommended today. Off the top of my mind:

* `synchronized` blocks

* raw types

* anonymous inner classes

* checked exceptions

as well as specific uses of otherwise fine language features:

* "AbstractX" style abstract classes when static and default interface methods suffice

* old-style POJO classes when records are a better choice

> Java has so few features that there's not much to ban

Exactly. Simplicity was an explicit design goal of Java.

Most items in your list are fine actually, including raw types and inner classes.

Regarding checked exceptions, it is unfortunate that people don't fully understand it, see here: https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...

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

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.

What stability issues?

Unchecked exceptions will eventually lead into programs crashing because some developer forgot to catch specific type of exception somewhere.

And developers never forget to check error codes.

Looking at code, it‘s easier to spot the missing check for an error code, than a not catched exceptions.

Also error codes are part of the signature of a function, which exceptions aren‘t.

If you need to wrap each call in try/catch, it's better to use return codes in some form or rethink the approach.

may I introduce you to the nodiscard attribute[1]?

  enum (class)? [[nodiscard]] Error {
    Ok,
    NoMem,
    ...
  };

   C attribute: nodiscard (since C23)

FWIW I’ve been using warn_unused_result in both gcc and clang since about 2020.

Yep, partial remedies are available for quite some time.

That seems like a better outcome than continuing when an error happened while thinking everything succeeded?

Yes, but that's not a dichotomy. Languages like Java have function declare what exceptions they throw, and the caller must either catch it or also declare that it throws it. Gets cumbersome quickly, but I believe it's for the best to encode exceptions at the type system.

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.

> In low-level systems software, which is a primary use case for C++

I don't this this is true. There is A LOT of C++ for GUI applications, video games, all kind of utilities, scientific computing and others. In fact, I find that the transition to "modern" alternatives from native GUI toolkits in C/C++ has led to a regression in UI performance in general. Desktop programs performed better 20 years ago when everything was written in Win32, Qt, GTK and others and people did not rely on bloated Web toolkits for desktop development. Even today you can really feel how much more snappy and robust "old school" programs are relative to Electron and whatnot.

To clarify, you think that low-level systems software is only a secondary use case for C++? The part you quoted does not make claims about whether there are other primary use cases, just that low-level systems software is one of them, so it's not clear why it being useful elsewhere is a rebuttal of that.

There are only so many OS kernels to be written. Nothing else is really low-level these days.

I don't think I agree with that. To me, how low-level something is makes more sense sense as a spectrum rather than a binary, and there are certainly other things that I'd consider to fit into the lower end than just OS kernels. Over the summer I contracted for a company making satellites working on software they had that facilitated interactions between various software and hardware components that had to run a 20 ms loop for processing everything, with delays cascading throughout those other components and causing systemic issues. This was all in userland (the OS stuff was managed by another team), but a tracing garbage collector would have been pretty much a non-starter due to the potential to miss the expected timing of a loop iteration.

You could handwave this objection by saying it's not "really" low level or that "nothing" was an exaggeration, but at that point it seems like we'd be back to the original question of why it's wrong to say that this isn't a primary use case for C++.

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

> That's true, except for languages that ensure you can't simply forget that something deep down the stack can throw an exception.

Sometimes it is not safe to unwind the stack. The language is not relevant. Not everything that touches your address space is your code or your process.

Exception handlers must have logic and infrastructure to detect these unsafe conditions and then rewrite the control flow to avoid the unsafety. This both adds overhead to the non-exceptional happy path and makes the code flow significantly uglier.

The underlying cause still exists when you don't use exceptions but the code for reasoning about it is highly localized and usually has no overhead because you already have the necessary context to deal with it cleanly.

> Sometimes it is not safe to unwind the stack.

This where garbage collected languages shine.

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.

For what it's worth, C++17 added [[nodiscard]] to address this issue.

You should compare exceptions to Result-style tagged unions in a language with exhaustiveness checks, like Rust. Not to return codes in C, lmao.

Everyone (except Go devs) knows that those are the worst. Exceptions are better, but still less reliable than Result.

https://home.expurple.me/posts/rust-solves-the-issues-with-e...

Rust is better here (by a lot), but you can still ignore the return value. It's just a warning to do so, and warnings are easily ignored / disabled. It also litters your code with branches, so not ideal for either I-cache or performance.

The ultimate ideal for rare errors is almost certainly some form of exception system, but I don't think any language has quite perfected it.

> you can still ignore the return value

Only when you don't need the Ok value from the Result (in other words, only when you have Result<(), E>). You can't get any other Ok(T) out of thin air in the Err case. You must handle (exclude) the Err case in order to unwrap the T and proceed with it.

> It also litters your code with branches, so not ideal for either I-cache or performance.

That's simply an implementation/ABI issue. See https://github.com/iex-rs/iex/

Language semantics-wise, Result and `?` are superior to automatically propagated exceptions.

> like Rust

Where people use things like anyhow.[0]

[0] https://docs.rs/anyhow/latest/anyhow/

Anyhow erases the type of the error, but still indicates the possibility of some error and forces you to handle it. Functionality-wise, it's very similar to `throws Exception` in Java. Read my post

As a matter of fact I did when it appeared on hn.

>forces you to handle it.

By writing `?`) And we get poor man's exceptions.

Poor man's checked exceptions. That's important. From the `?` you always see which functions can fail and cause an early return. You can confidently refactor and use local reasoning based on the function signature. The compiler catches your mistakes when you call a fallible function from a supposedly infallible function, and so on. Unchecked exceptions don't give you any of that. Java's checked exceptions get close and you can use `throws Exception` very similarly to `anyhow::Result`. But Java doesn't allow you to be generic over checked exceptions (as discussed in the post). This is a big hurdle that makes Result superior.

>Poor man's checked exceptions.

No, it's not quite the same. Checked exceptions force you to deal with them one way or another. When you use `?` and `anyhow` you just mark a call of fallible function as such (which is a plus, but the it's the only plus), and don't think even for a second about handling it.

Checked exceptions don't force you to catch them on every level. You can mark the caller as `throws Exception` just like you can mark the caller as returning `anyhow::Result`. There is no difference in this regard.

If anything, `?` is better for actual "handling". It's explicit and can be questioned in a code review, while checked exceptions auto-propagate quietly, you don't see where it happens and where a local `catch` would be more appropriate. See the "Can you guess" section of the post. It discusses this.

> If you forget to handle a C++ exception you get a clean crash

So clean that there's no stack trace information to go with it, making the exception postmortem damn near useless.

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

Oops, I meant they are ABI locked so sad path cannot be fixed.

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

FWIW, I think it is possible to make exception-like error handling work. A lot of systems code has infrastructure that looks like an exception handling framework if you squint.

There are two main limitations. Currently, the compiler has no idea what can be safely unwound. You could likely annotate objects to provide this information. Second, there is currently no way to tell the compiler what to do with an object in the call stack may not be unwound safely.

A lot of error handling code in C++ systems code essentially provides this but C++ exceptions can't use any of this information so it is applied manually.

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:

https://youtu.be/LorcxyJ9zr4

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.

Unchecked exceptions is a design flaw of C# see here: https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...

I usually see articles saying that Java checked exceptions are bad.

e.g. https://www.javacodegeeks.com/2026/01/javas-checked-exceptio...

It really depends on how reliable you want the code to be. Many business application developers prioritize development speed and don't want to think about errors, for them checked exceptions may seem like a hassle. For developers who prioritize reliability unchecked exceptions are a huge problem because they are not part of the contract and can change without notice.

Because java is garbage-collected and doesn't have any of the problems of C++ exceptions, so checked exceptions just become a nuisance of having to try/catch everything.

You don't have to try/catch everything.

You do have to catch checked exceptions and that is the issue under debate.

No, you can just declare that the exception in the throws clause.

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

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

The code that's throwing an exception typically does not know that the exception catcher will shut anything down.

And - very often, you would _not_ shut down. Examples:

* Failure/error in an individual operation or action does not invalidate all others in the set of stuff to be done.

* Failure/error regarding the interaction with one user does not mean the interaction with other users also has to fail.

* Some things can be retried after failing, and may succeed later: I/O; things involving resource use, etc.

* Some actions have more than one way to perform them, with the calling code not being able to know apriori whether all of them are appropriate. So, it tries one of them, if it fails tries another etc.

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

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.

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.

Rust is too complicated!!11 Ooops wrong thread.

C++ itself should be forever banned

Ok. You can stop using anything written in C++.

How would you implement a C++ ban in Chromium?

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.

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?

You know uBlock Origin Lite works great with v3 and is significantly faster than v2. I actually prefer it.