Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Dark Side of C++ (2007) [pdf]

fefe.de

Post reply on HN
Print view View original

51–55 of 55 posts

Re: The Dark Side of C++ (2007) [pdf]

#51

Post by blt »

rspring wrote: post #45
tapatio wrote: post #44

Earlier quoted context omitted.

Better stated, there are applications where you can't use JavaScript or Python due to timing requirements - software defined radios for instance.

I agree. And that's exactly why there exist interface languages such as JNI so you can write your higher level code in a nice language and get down to C/C++ for the time-critical parts. I don't see much of a problem here.

This introduces a whole new category of pains in the ass. You need to run two debuggers at the same time. Inverting control with callback interfaces is tricky. there can be friction between the memory ownership models in the managed and native code. And it just makes the system that much more complex. I've been working in a python / c++ interop system for a while and I think some of the c++11 features make the benefits pretty questionable.

Re: The Dark Side of C++ (2007) [pdf]

#52

Post by cliffbean »

ycombobreaker wrote: post #46
betterunix wrote: post #24

Earlier quoted context omitted.

"I.e. instead of manual close calls you let the destructor handle it. This is both exception-safe and spares you remembering to add a close call on every possible exit-path." Unless closing the handle causes an exception to be thrown. Either you never see the exception or your program aborts, and neither one is particularly good if you want to write reliable code.

"Unless closing the handle causes an exception to be thrown." That is a straw-man argument. If the underlying file-closing API can throw exceptions, they must be caught from the destructor. If that means that they get ignored, then that is what it will have to be (much the same as most C programs ignore the return call from `printf`). Also in this case, the RAII wrapper should provide a member function which can exec…

> in this case, the RAII wrapper should provide a member function which can execute the underlying close call early and expose the failure, for users who may be interested in guaranteed reliability.

Indeed; this is a useful technique. However, it means that you now have a close() method which you have to call on every exit path, because if you miss a path, that's a path which could have an exception thrown from a destructor. And that basically means you're not doing RAII anymore.

So yes, RAII is intrinsically incompatible with this kind of reliability.

Re: The Dark Side of C++ (2007) [pdf]

#53

Post by ycombobreaker »

cliffbean wrote: post #52
ycombobreaker wrote: post #46

Earlier quoted context omitted.

"Unless closing the handle causes an exception to be thrown." That is a straw-man argument. If the underlying file-closing API can throw exceptions, they must be caught from the destructor. If that means that they get ignored, then that is what it will have to be (much the same as most C programs ignore the return call from `printf`). Also in this case, the RAII wrapper should provide a member function which can exec…

> in this case, the RAII wrapper should provide a member function which can execute the underlying close call early and expose the failure, for users who may be interested in guaranteed reliability. Indeed; this is a useful technique. However, it means that you now have a close() method which you have to call on every exit path, because if you miss a path, that's a path which could have an exception thrown from a des…

> However, it means that you now have a close() method which you have to call on every exit path, because if you miss a path, that's a path which could have an exception thrown from a destructor.

Not true at all. `close` and the destructor should be idempotent. In the main path, `close` will get called and failure will propogate upward. In any other failure path, the destructor will attempt to perform the underlying close and allow the stack to unwind without any further interruption.

Of course, anyone can come up with pathological cases where this is not acceptable behavior from a high-reliability sub-component. And in such a situation, RAII may not be the best answer (nor would lexical scoping i.e. constructor/destructor, for that matter!) But in my experience, this approach is just fine for most application-level code.

Re: The Dark Side of C++ (2007) [pdf]

#54

Post by JoeAltmaier »

mrich wrote: post #28
JoeAltmaier wrote: post #27

Earlier quoted context omitted.

To be fair, template error messages are still a black art. They can take half a page. Reminds me of the old CFront days when C++ compiler was a front-end for another compiler. Templates are not very well integrated still.

clang has solved this problem mostly with their template type diffing. gcc has also improved in that area. http://clang.llvm.org/diagnostics.html

Cool, but the template examples leave me unconvinced. When I get to work, I'll paste in an epic template error; hard to see how clang could make it all better :)

Re: The Dark Side of C++ (2007) [pdf]

#55

Post by betterunix »

ycombobreaker wrote: post #53
cliffbean wrote: post #52

Earlier quoted context omitted.

> in this case, the RAII wrapper should provide a member function which can execute the underlying close call early and expose the failure, for users who may be interested in guaranteed reliability. Indeed; this is a useful technique. However, it means that you now have a close() method which you have to call on every exit path, because if you miss a path, that's a path which could have an exception thrown from a des…

> However, it means that you now have a close() method which you have to call on every exit path, because if you miss a path, that's a path which could have an exception thrown from a destructor. Not true at all. `close` and the destructor should be idempotent. In the main path, `close` will get called and failure will propogate upward. In any other failure path, the destructor will attempt to perform the underlying…

...or we could retool exceptions so that destructor exceptions are safe (as long as they are caught). Conditions in Common Lisp, for example:

http://www.gigamonkeys.com/book/beyond-exception-handling-co...

Post reply on HN