De-fragmenting C++: Making Exceptions and RTTI More Affordable and Usable - Herb Sutter CppCon 2019

What Hacker News said

Recommends je42 · 2020-01 · on “Tim Sweeney: Eliminating C++ exceptions gave 15% speedup”

Quite an improvement. However, i feel like that the tweet also displays the (sometimes emotional) feelings toward exceptions that a large part of the C++ community has. Herb Sutter made an excellent presentation about this "fragmentation" of the community and steps towards fixing this split: [this video]

Recommends Felk · 2020-02 · on “Investigating the Performance Overhead of C++ Exceptions”

If you want to see Herb Sutter's take on exceptions (and RTTI), I can really recommend this talk where he explores his Result-esque (like in Rust) solution that he wrote a paper about and proposes for standardisation: [this video]

Recommends je42 · 2020-12 · on “These Modern Programming Languages Will Make You Suffer”

Wow: C++ > Garbage collection was never added into C++. Manual memory management is extremely error prone. C++ has memory management simplification: reference couting via shared_ptr/unique_ptr. The trade-offs are different, but in C++ manually managing memory is not necessary unless you have a good reason. > C++ is notorious for its slow compilation time. Significantly slower than Java, not as bad as Scala. That depends on what you use and how you use it. However, this is tricky to figure out what slows down the compilation. > In C++, all references are nullable. Looks like this guy really needs to read up on C++. References can point to null, but not so easily. I think he means pointers. >

Recommends inetknght · 2025-09 · on “How is Ultrassembler so fast?”

> I don't have enough time to watch these kinds of presentations. Then let me pick and share some of my favorites that I found enlightening, and summarize with some information that I found useful. By far, the most useful one is Khalil Estell's presentation last year [0]. It's a fairly face paced but relatively deep dive into exception mechanics. At the end, he advocates for a new tool that would audit a program to determine what exceptions could be thrown. I think that's a flipping fantastic idea for a tool. Unfortunately I haven't seen any progress toward it -- if someone here knows where his tool is, or a similar tool, please reply! I did send him an email a few months ago inquiring about

Cites TuxSH · 2020-02 · on “TOML for Modern C++”

According to a recent talk from Herb Stutter ( [this video] ), as many as 20% of users fully ban exceptions and an additional 30% ban them partially. Even code doesn't actually reach the throwing paths, exceptions and RTTI induce a huge binary size overhead that is simply not acceptable if you have binary size constraints.

Cites fpoling · 2020-03 · on “Secure Rust Guidelines”

[this video] mentioned that the notion that C++ could handle out-of-memory was a purely theoretical wishful thinking. In practice it could not.

Cites sideeffffect · 2020-12 · on “Orthodox C++”

I'm not a C++ developer, but AFAIK the fact that C++ is not 100% "you don't pay for what you don't use" is commonly acknowledged. Exceptions are an example of that. There are ideas/proposals how to fix that: [this video]

Cites oconnor663 · 2022-02 · on “Fork() is evil; vfork() is goodness; afork() would be better; clone() is stupid”

> the reason the "safe" Rust programming language leaves software vulnerable to DOS attacks if it uses the standard library Linux overcommitment is often cited as an argument for the "panic on OOM" design of the allocating parts of the Rust standard library, and it's an important part of the story. But I think even if the Linux defaults were different, Rust would still have gone with the same design. For example, here's Herb Sutter (who works for Microsoft) arguing that C++ would benefit from aborting on allocation failure: [this video] . The argument is that the vast majority of allocations in the vast majority of programs don't have any reasonable options for handling an alloc failure besides a