Real cost of C++ exception vs error-code checking • Hacker News Board

Re: Real cost of C++ exception vs error-code checking

#51

Post by cpeterso » Wed, Mar 09, 2011, 1:53 AM UTC

snprbob86 wrote: post #9

bostonpete wrote: post #6

Earlier quoted context omitted.

"since you have to check every single line of code (indeed, every sub-expression) and think about what exceptions it might raise and how your code will react to it" Yes, that's my concern with exceptions as well. It seems like the Java model (if I remember it right -- it's been a decade), which requires a method to either handle an exception that a sub-method throws or explicitly allow it to be thrown, would be prefe…

You're thinking of "checked exceptions" and C++ already has them (pre 0X) via the "throws" clause on method declarations. Checked exceptions is a hotly debatted topic and I think the world has kinda finally come around to deciding that the are a bad idea overall. Google it and see for yourself.

As mentioned, C++ exception specifications are checked at run-time, not compile-time. And if your function's exception specification declares `throws(FooException)` and you call some third-party library function (which may or may not have its own exception specification!) that throws a `BarException`, C++'s runtime checks will `terminate()` your program!

C++ exceptions and exception specifications are pretty much all the worst possible design decisions. :(

Re: Real cost of C++ exception vs error-code checking

#52

Post by johnny531 » Wed, Mar 09, 2011, 2:48 AM UTC

JoeAltmaier wrote: post #47

Perhaps the worst problem with checking-vs-exceptions is, either solution dominates your code structure, obscuring the algorithm logic. The holy grail would be some method of ensuring the code cannot fail e.g. weirdly constrained argument semantics. Thus separating algorithm from constraints instead of shuffling them together on the page like a deck of cards.

If only c++ had some sort of static type system which could be leveraged to provide compile-time checks...

But seriously, this is a large part of the power of c++'s type system. Taking the article's example, if the argument types were of (user class) 'non_zero_float', there's no possibility for error.

You still have to check that your input is non-zero at some point, but you've now focused it into one place (the 'non_zero_float' class ctor), and other chunks of your program depending on those type semantics no longer need to worry about it.

Re: Real cost of C++ exception vs error-code checking

#53

Post by johnny531 » Wed, Mar 09, 2011, 2:53 AM UTC

svlla wrote: post #13

AshleysBrain wrote: post #7

Earlier quoted context omitted.

This reads to me like 'writing good code is hard, and writing even better code is even harder'. With modern C++0x smart pointers (like unique_ptr) and RAII, you can get very high performance and (more) easily exception-safe code. Maybe a lot of C++ exception criticism comes from people still trying to code like C in C++?

"modern C++" has changed meanings so many times in the past 10 years that it's not funny anymore. there's always some "modern" solution in C++ that ends up causing more problems, leading to further "modern" solutions that end up... you get my point. some folks have decided to get off the C++ feature treadmill and go back to, well... getting things done with solid languages (e.g. C) instead of learning about the lates…

Really? C++ is perhaps the slowest moving language in my repertoire in terms of 'popular' approaches to solving common problems. Look how long a c++0x specification has taken.

And also, www.boost.org. Don't code c++ without it.

Re: Real cost of C++ exception vs error-code checking

#54

Post by ekiru » Wed, Mar 09, 2011, 3:03 AM UTC

SoftwareMaven wrote: post #45

bostonpete wrote: post #6

Earlier quoted context omitted.

"since you have to check every single line of code (indeed, every sub-expression) and think about what exceptions it might raise and how your code will react to it" Yes, that's my concern with exceptions as well. It seems like the Java model (if I remember it right -- it's been a decade), which requires a method to either handle an exception that a sub-method throws or explicitly allow it to be thrown, would be prefe…

Requiring all exceptions to be checked is evil. It leads to horrendous abstraction leakage (I need to let every caller know I use FooBarWidget in the core of my application??), improper error handling (just catch whatever comes out and move on so I don't have to declare it), or ubiquitous error wrapping (every class has a try...catch that turns the called exceptions into new exception types to throw). Ironic that C++…

> It leads to horrendous abstraction leakage (I need to let every caller know I use FooBarWidget in the core of my application??),

If your code catches any exceptions that might be thrown by its use of FooBarWidget, then you wouldn't need to specify it as an exception that your code might throw, right? If it doesn't, then your code exposes to callers that it uses FooBarWidget every time FooBarWidget throws an exception.

Re: Real cost of C++ exception vs error-code checking

#55

Post by johnny531 » Wed, Mar 09, 2011, 3:04 AM UTC

cpeterso wrote: post #49

AshleysBrain wrote: post #7

Earlier quoted context omitted.

This reads to me like 'writing good code is hard, and writing even better code is even harder'. With modern C++0x smart pointers (like unique_ptr) and RAII, you can get very high performance and (more) easily exception-safe code. Maybe a lot of C++ exception criticism comes from people still trying to code like C in C++?

But your exception-safe C++ code soon becomes bloated with shared_ptr and unique_ptr templates and copy ctors. Almost any C++ function, overloaded operator, or some implicit temporary object's ctor can throw an exception without warning. You must use RAII everywhere for every "resource". Exception-safe RAII is pretty much an all-or-nothing affair.

Not sure what you mean with copy ctor bloat, but for your_flavor_of_smart_ptr, that's what the typedef keyword is for.

A common idiom I use is to typedef a class's preferred smart-pointer as ptr_t within the class namespace. Passing them around now looks like:

void some_function(my_class::ptr_t);

Exception safe, clear semantics, & no bloat.

Re: Real cost of C++ exception vs error-code checking

#56

Post by Retric » Wed, Mar 09, 2011, 3:10 AM UTC

faragon wrote: post #35

T-hawk wrote: post #12

Earlier quoted context omitted.

Sure they have. My 486 built in 1993 had 8 KB cache, 4 MB RAM, and a 120 MB HD. My desktop built in 2009 has 2 MB cache, 2 GB RAM, and a 250 GB HD. Okay, the cache has lagged behind by one or three doublings compared to the other storage types. But that's still pretty close to proportional in a world of exponential gains.

I bet that your 1993 486 had 256KB of L2 cache on the motherboard, so from 256KB to 2MB is less than 10 times, for 500 times the RAM and 2000 times the hard disk size.

The value of Cache does not increase linearly with size. You also run into latency issues, so Having L4 cache on a modern motherboard would have little value.

Re: Real cost of C++ exception vs error-code checking

#57

Post by gersh » Wed, Mar 09, 2011, 3:36 AM UTC

A few issues. Does he actually benchmark? Things don't always work in practice the way you would think.

If you are going for ultra-high performance, do you even have error-checking? Do you write it in assembler?

Re: Real cost of C++ exception vs error-code checking

#58

Post by dkarl » Wed, Mar 09, 2011, 3:44 AM UTC

svlla wrote: post #13

AshleysBrain wrote: post #7

Earlier quoted context omitted.

This reads to me like 'writing good code is hard, and writing even better code is even harder'. With modern C++0x smart pointers (like unique_ptr) and RAII, you can get very high performance and (more) easily exception-safe code. Maybe a lot of C++ exception criticism comes from people still trying to code like C in C++?

"modern C++" has changed meanings so many times in the past 10 years that it's not funny anymore. there's always some "modern" solution in C++ that ends up causing more problems, leading to further "modern" solutions that end up... you get my point. some folks have decided to get off the C++ feature treadmill and go back to, well... getting things done with solid languages (e.g. C) instead of learning about the lates…

C++ isn't a language like Java where language features and coding styles are handed down from on high. You get to -- you have to -- make your own decisions about which language features are useful for which purposes. Announcements of new C++ features are not, and never were, declarations that the "right way to code" was about to change. Nobody forced you to change the way you coded except by offering better ways, and what's the harm in that? Your "feature treadmill" is not compulsory unless you compulsively keep up with the Joneses (the Alexandrescus? but apparently he has moved on to D now.) The C++ coding style where I work has been the same for at least five years. The C++ coding style at my old shop evolved a little while I was there, but only because I wrote most of the code and was still learning, not because we were adopting new language features.

Anyway, have fun with C; it is certainly a language where you won't run into solutions to any problems you don't have, or solutions for very many other problems, for that matter.

P.S. Andrei Alexandrescu's book Modern C++ Design was published in 2001. That's ten years ago. How much has changed between then and now?

Re: Real cost of C++ exception vs error-code checking

#59

Post by dkarl » Wed, Mar 09, 2011, 3:58 AM UTC

jerf wrote: post #37

AshleysBrain wrote: post #26

Earlier quoted context omitted.

Hmm, well, I'm relatively young so I guess I missed all those broken promises :P Still, I think the "trying to code like C in C++" point still stands.

A compressed version can be obtained simply by comparing the initial release of C++ to modern C++, and recalling that the initial version of C++ itself shipped with, well, pretty much the same set of promises that modern C++ ships with.

Do you mean when it was called C with Classes in 1979, or when they changed the name to C++ in 1983? That's about three decades of change either way. A book about the history and evolution of C++ came out in 1994, a year before the first public release of Java. More time has passed since that book was released than between the invention of C with Classes and the publication of that book. When a language has been around for thirty years, it's hard to perceive its rate of change correctly relative to other languages. It would be best compared to Perl, which is only eight years younger, and which is also still thriving. C++ is actually a pretty slow-moving language.

Re: Real cost of C++ exception vs error-code checking

#60

Post by faragon » Wed, Mar 09, 2011, 7:25 AM UTC

Retric wrote: post #56

faragon wrote: post #35

Earlier quoted context omitted.

I bet that your 1993 486 had 256KB of L2 cache on the motherboard, so from 256KB to 2MB is less than 10 times, for 500 times the RAM and 2000 times the hard disk size.

The value of Cache does not increase linearly with size. You also run into latency issues, so Having L4 cache on a modern motherboard would have little value.

The value of cache memory is the "hit ratio". If increasing cache size by 50% increases cache-hit from 95% to 99%, is worth it, as the 5% of cache-misses could reduce CPU performance to one half.