Exceptions in C++ are never zero-overhead. There is a time-space tradeoff for performance of uncaught exceptions, and G++ picks space over time.

▲

mpyne 6 days ago | parent | next [-]

There's a time-space tradeoff to basically any means of error checking.

Including checking return codes instead of exceptions. It's even possible for exceptions as implemented by g++ in the Itanium ABI to be cheaper than the code that would be used for consistently checking return codes.

▲

Joker_vD 5 days ago | parent [-]

Actually, there has been some research into building exceptions on the "basically, passing std::exception* into every function and checking what's inside it on every return" idea, and it was about as fast as the traditional table-based unwinding, took way less space in the executable, and re-throwing exceptions was actually faster [0][1]

[0] https://news.ycombinator.com/item?id=22483028

[1] https://www.research.ed.ac.uk/portal/files/78829292/low_cost...

	▲	mpyne 5 days ago \| parent [-]
		Yeah, it comes down to modeling assumptions on how many different types of exceptions can be thrown, how many actually are thrown, and the shape of the control flow graph of a program at runtime. You can find one style outperforms the other based on the circumstances of the program, and programmers worried about optimization may someday be able to choose between approaches to meet their performance goals instead of pretending that tables are inherently slow and return codes that they won't even fully implement are inherently fast. My point was simply that you can't just say "oh but exceptions are not zero-cost" without actually comparing to the alternative of laboriously carting return codes all through the call graph, as done in the research you show here and as also done by Khalil Estell elsewhere for ARM embedded.

▲

netr0ute 6 days ago | parent | prev [-]

> G++ picks space over time

By definition, that's zero-overhead because Ultrassembler doesn't care about space.

	▲	aidenn0 6 days ago \| parent [-]
		Okay, than a traditional setjmp/longjmp implementation is zero-overhead because I don't care about space or time!