←back to thread

327 points AareyBaba | 5 comments | | HN request time: 0.217s | source
Show context
mwkaufma ◴[] No.46183728[source]
TL;DR

- no exceptions

- no recursion

- no malloc()/free() in the inner-loop

replies(9): >>46183820 #>>46183900 #>>46184073 #>>46184113 #>>46184198 #>>46184398 #>>46184472 #>>46184588 #>>46185500 #
1. krashidov ◴[] No.46184398[source]
Has anyone else here banned exceptions (for the most part) in less critical settings (like a web app)?

I feel like that's the way to go since you don't obscure control flow. I have also been considered adding assertions like TigerBeetle does

https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TI...

replies(3): >>46184593 #>>46185874 #>>46185984 #
2. mwkaufma ◴[] No.46184593[source]
Lots of games, and notably the Unreal Engine, compile without exceptions. EASTL back in the day was in part written to avoid the poor no-exception support in Dinkumware STL and STLport.
replies(1): >>46186856 #
3. tonfa ◴[] No.46185874[source]
Google style bans them: https://google.github.io/styleguide/cppguide.html#Exceptions
4. fweimer ◴[] No.46185984[source]
Most large open-source projects ban exceptions, often because the project was originally converted from C and is just not compatible with non-local control flow. Or the project originated within an organization which has tons of C++ code that is not exception-safe and is expected to integrate with that.

Some large commercial software systems use C++ exceptions, though.

Until recently, pretty much all implementations seemed to have a global mutex on the throw path. With higher and higher core counts, the affordable throw rate in a process was getting surprisingly slow. But the lock is gone in GCC/libstdc++ with glibc. Hopefully the other implementations follow, so that we don't end up with yet another error handling scheme for C++.

5. jesse__ ◴[] No.46186856[source]
Basically all high profile engine teams I know of ban exceptions. They're worse than useless