Ask HN: Big C++ projects that uses Exceptions and RTTI?

15 points by kwant_kiddo 2 years ago | 4 comments

In my career the places I have been that uses C++ (with success) have all been using -fno-exceptions and -fno-rtti. All major open-source C++ projects seem to do the same. Chromium, LLVM, Electron, protobuf etc.

I guess if you want to excel at this language and build software (in C++) that people actually use you have to learn to use it without exceptions and rtti?

Some projects do use them like CMake. I think bloomberg also uses exceptions??

Maybe Meta also uses them but again if you look at another Meta C++ project like Hermes they prohibit use of both rtti and exceptions.

Do you use exceptions in your codebase? If you intend to keep coding in C++ are you not better off learning how to use the language without exceptions and rtti?

trws 2 years ago |

It depends a great deal on your situation. Where I work, we have codes up to 3 million lines, they all have exceptions and rtti turned on. You’ll find similar situations all over except at google and in gaming, and to some extent anywhere that last quartile latency is a serious concern. The thing about exceptions is that when you throw none of them they cost almost nothing, but throwing one costs on average about 1000 times as much as returning a value would. It’s a massive hit, especially if you care about latency, so it’s best to avoid them for control flow or anything but truly exceptional situations.

RTTI I’d say it’s best to only use in testing and debugging generally, it just plain isn’t reliable for the uses people seem to try to put it to.

kwant_kiddo 2 years ago | |

Okay, do you think the effort is worthwhile? Or do you think migrating to a language with a bigger runtime would have been a better choice? Because that is usually the conclusion I make. If you can afford that the compiler emits code for exception handling in all your functions and pay rtti then maybe your problem does not need that kind of performance in the first place. And you get all the downsides of using C++, and don't benefit from the upsides => just write it in go/java/c#

I think another big issue is the complexity overhead of 'introducing' exceptions in a already complicated language. When you use exceptions the control flow of the program gets 'invisible' should you recover from a exception.

Also, just writing data structures in general that obeys the weak and/or strong exception guarantee is not very easy [1].

Like it makes writing (correct) C++ even harder than it already is.

[1]: https://en.cppreference.com/w/cpp/language/exceptions

trws 2 years ago | | |

We need the performance, and are frequently at least testing if not running in production on bleeding edge hardware, which almost always supports c/c++ first. That doesn’t make it for everyone though, and honestly I normally tell people to avoid exceptions as much as possible. The big issue is that C++ as a language was designed with exceptions in mind. There is no other way to exit with failure from any constructor that the caller can deal with, so every non-exception class has to use a two-step setup to avoid throwing in the constructor. If you’re doing exception free for real, meaning you can still recover rather than turning them off and just letting the program abort whenever a throw would have occurred, it’s actually a much harder language to write for.

Don’t get me wrong, maintaining exception guarantees and ensuring exceptions are appropriately caught is terrible. I much prefer working with optional and outcome and similar personally, but the assumption of exceptions is very deeply baked in, and avoiding them safely is a lot harder than one might guess.

Also, remember that while exceptions cost code size, they cost literally nothing in instructions executed unless an exception is actually thrown. That’s why the common nix implementation is called “zero cost exceptions”. In the happy path case they are faster than returning a discriminant. It’s not having exceptions available that makes code slow, it’s using them for things that are expected rather than unexpected or for control flow.