3 ms·

Why didn't c++ implement rustlike Result types instead of exceptions?

kelseyfrog 4y ago
Exceptions were added after CFront 2.0[1] but before/concurrent to the Annotated C++ Reference Manual[2] release which served as the de facto standard until the ISO[3]. The Annotated C++ Reference Manual itself references "Andrew Koenig and Bjarne Stroustrup: Exception Handling for C+ (revised), Proc. USENIX C+ Conference, San Francisco, April 1990."[4] In fact there is a hint at the design considerations in the latter "an implementation that has no run-time costs when exceptions do not occur." Perhaps a question to Rust users, is Result zero-overhead? The answer to that may be the same. The C++ Reference Manual continues: > The design here and the criteria for it evolved slowly. An earlier version of the design was presented at the ‘C+ at Work” conference in November 1989 by Andrew Koenig and Bjame Stroustrup. The design presented here owes much to the discussion generated by that paper and in particular to comments by Toby Bloom, Peter Deutch, Ken Friedenbach, Keith Gorlen, Michael O'Riorden, Mike Powell, Jim Mitchell, Rob Seliger, Jonathan Shopiro, and Mike Tiemann. The design is clearly influenced by the exception handling mechanism in ML. Another important source of inspiration was the work on fault-tolerant systems done in the University of Newcastle in England under the direction of Brian Randel. 1. the "catch" keyword had been reserved, but unused at the time https://www.softwarepreservation.org/projects/c_plus_plus/cfront/release_2.0/doc/ReleaseNotes.pdf https://www.softwarepreservation.org/projects/c_plus_plus/cf... (4-8) 2. https://archive.org/details/annotated-c-reference-manual/page/n7/mode/2up https://archive.org/details/annotated-c-reference-manual/pag... 3. Exceptions are described as "experimental" https://en.cppreference.com/w/cpp/language/history https://en.cppreference.com/w/cpp/language/history 4. https://www.stroustrup.com/except89.pdf https://www.stroustrup.com/except89.pdf
- WirelessGigabit 4y ago
  How was a failure represented before exceptions?
- duped 4y ago
  Code that doesn't return Result will have no runtime cost added just like code that doesn't have a throw statement doesn't. Code that returns Result but is always Ok will have a very small overhead just like code that can't provably never throw will. But I'd wager it's extremely small given that on modern CPUs branches never taken are much cheaper than they were in 1990. To put it in more plain terms, the reason that C++ exceptions have "no overhead" when an exception occurs is that the exception handler code will only be dispatched when an exception is raised. The same is true of error handlers in Rust. No Err, no handler called. The difference is the branch is always there. So the question in 2022 is, how expensive is a branch that is never reached? Today it is basically nil, depending on your hardware. Branch predictors are pretty good and pretty ubiquitous (nb4 someone comes talking about how this wouldn't work on their Blackfin ADSP or whatever - neither will exceptions!). There is a small overhead though in that there are two branches. The other nuance is stack unwinding. But in practice this is generally a good thing in debug builds that you can disable in release if you want to. At the end of the day, the practice is for users not to write or call code that may error or propagate errors when the utmost performance is required. Inputs get validated up front and fail fast so the hot loops maximize performance.
  - bruce343434 4y ago
    > very small overhead > I'd wager ... extremely small > much cheaper now > basically nil, depending on hardware > pretty good > small overhead So that's a lot of opinions. I mostly sense wishful thinking. Benchmarks please?

Exceptions were added after CFront 2.0[1] but before/concurrent to the Annotated C++ Reference Manual[2] release which served as the de facto standard until the ISO[3]. The Annotated C++ Reference Manual itself references "Andrew Koenig and Bjarne Stroustrup: Exception Handling for C+ (revised), Proc. USENIX C+ Conference, San Francisco, April 1990."[4] In fact there is a hint at the design considerations in the latter "an implementation that has no run-time costs when exceptions do not occur." Perhaps a question to Rust users, is Result zero-overhead? The answer to that may be the same. The C++ Reference Manual continues: > The design here and the criteria for it evolved slowly. An earlier version of the design was presented at the ‘C+ at Work” conference in November 1989 by Andrew Koenig and Bjame Stroustrup. The design presented here owes much to the discussion generated by that paper and in particular to comments by Toby Bloom, Peter Deutch, Ken Friedenbach, Keith Gorlen, Michael O'Riorden, Mike Powell, Jim Mitchell, Rob Seliger, Jonathan Shopiro, and Mike Tiemann. The design is clearly influenced by the exception handling mechanism in ML. Another important source of inspiration was the work on fault-tolerant systems done in the University of Newcastle in England under the direction of Brian Randel. 1. the "catch" keyword had been reserved, but unused at the time https://www.softwarepreservation.org/projects/c_plus_plus/cfront/release_2.0/doc/ReleaseNotes.pdf https://www.softwarepreservation.org/projects/c_plus_plus/cf... (4-8) 2. https://archive.org/details/annotated-c-reference-manual/page/n7/mode/2up https://archive.org/details/annotated-c-reference-manual/pag... 3. Exceptions are described as "experimental" https://en.cppreference.com/w/cpp/language/history https://en.cppreference.com/w/cpp/language/history 4. https://www.stroustrup.com/except89.pdf https://www.stroustrup.com/except89.pdf

WirelessGigabit 4y ago
How was a failure represented before exceptions?
duped 4y ago
Code that doesn't return Result will have no runtime cost added just like code that doesn't have a throw statement doesn't. Code that returns Result but is always Ok will have a very small overhead just like code that can't provably never throw will. But I'd wager it's extremely small given that on modern CPUs branches never taken are much cheaper than they were in 1990. To put it in more plain terms, the reason that C++ exceptions have "no overhead" when an exception occurs is that the exception handler code will only be dispatched when an exception is raised. The same is true of error handlers in Rust. No Err, no handler called. The difference is the branch is always there. So the question in 2022 is, how expensive is a branch that is never reached? Today it is basically nil, depending on your hardware. Branch predictors are pretty good and pretty ubiquitous (nb4 someone comes talking about how this wouldn't work on their Blackfin ADSP or whatever - neither will exceptions!). There is a small overhead though in that there are two branches. The other nuance is stack unwinding. But in practice this is generally a good thing in debug builds that you can disable in release if you want to. At the end of the day, the practice is for users not to write or call code that may error or propagate errors when the utmost performance is required. Inputs get validated up front and fail fast so the hot loops maximize performance.
- bruce343434 4y ago
  > very small overhead > I'd wager ... extremely small > much cheaper now > basically nil, depending on hardware > pretty good > small overhead So that's a lot of opinions. I mostly sense wishful thinking. Benchmarks please?