Live data from Hacker News

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

lazarenko.me

61–64 of 64 posts

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

#61

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.

"But your exception-safe C++ code soon becomes bloated with shared_ptr and unique_ptr templates and copy ctors."

You need to prove that, I think it's a bogus claim. There is no reason why good template code should be any larger than its hand-written equivalent. Any decent optimizing compiler will take care of the rest.

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

#62

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.

You can't prevent exceptions when you do IO or dynamically allocate memory.

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

#63

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…

You can really make that type do a compile-time check on runtime values?

It would be better to have some way of getting the compiler to optimize constraints, perhaps by proving at compile time that the error is impossible.

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

#64
post #30

Earlier quoted context omitted.

when is the binary size a more important factor than both execution speed and ease of development? Binary size (or maybe more accurately in this case, binary code layout) can be highly relevant for speed due to the instruction cache. As for ease of development, there are issues with C++ exceptions regarding this as well: some C++ libraries aren't exception safe, and neither are practically all C libraries. This is so…

Binary working set sizes are often lower with exceptions than without, because exception handling code can be moved elsewhere by the compiler. Error-checking code, on the other hand, cannot be so easily detected, and hence moved. I think the C++ implementation of exceptions has a lot to answer for though, in poisoning too many developers on the concept. It really is an awful implementation.

C++ seems full of missed opportunities. I fear a lot of them are due to the slavish backward compatibility to C.
Post reply on HN