111–115 of 115 posts
Anyone know what these guidelines are talking about when they refer to a 'final_action' object, or the function/keyword 'finally'? I'm referring to E.19. I could not get the example below to compile even using the newest gcc with -std=c++1y at godbolt.org. It seems potentially useful, if it actually exists. https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
Earlier quoted context omitted.
> a) you can catch a segfault, too, by installing a signal handler, My POSIX knowledge is a bit out of date, but if I remember correctly what actually happens is not guaranteed to work across all UNIXes.
Good luck getting a fully C++14 compatible compiler with exceptions working on all UNIXes.
Besides, signals are OS specific, while C++ exceptions are compiler specific.
Earlier quoted context omitted.
> a) you can catch a segfault, too, by installing a signal handler, My POSIX knowledge is a bit out of date, but if I remember correctly what actually happens is not guaranteed to work across all UNIXes.
Good luck getting a fully C++14 compatible compiler with exceptions working on all UNIXes.
what do you put in "all UNIXes" ? Xenix 1.0 ? MULTICS? Because all current unices (https://upload.wikimedia.org/wikipedia/commons/7/77/Unix_his...) would have no problem running recent GCC and C++ exceptions.
I mean, for hell's sake, C++ exceptions date back to 1990. Nowadays you can throw exceptions on damn 16-bit microcontrollers (https://en.wikipedia.org/wiki/TI_MSP430) ; I doubt there's a relevant, non legacy unix where this does not work.
Earlier quoted context omitted.
Bjarne's guidance has always been to use exceptions only in truly exceptional circumstances. A function that might occasionally fail on bad user input could instead return a std::optional and be marked noexcept (assuming it really doesn't throw). A function that fails to allocate memory, on the other hand, is truly exceptional, so throw std::bad_alloc. The STL unfortunately doesn't always follow this approach, and te…
since optional is a thing now and the standards committee isn't afraid of verbosity maybe we can get std::value_or_error ;)
Earlier quoted context omitted.
Exceptions are a mistake, plain and simple. They should have never been added to the language. They break the notion of programming as a sequence of events. With exceptions, now you have two sequences, the happy path and the 'wherever the hell the exception is caught' path. No matter how you slice it, exceptions are still a goto under the covers. If they are truly exceptional, you might as well call exit() too. Go go…
> No matter how you slice it, exceptions are still a goto under the covers. This is a poor argument; the same could be said for almost all control flow statements: if/else, while, for, break, continue, (early)return ... they're all implemented using "goto under the covers". Moreover, lots of C programs use goto to do their error handling! Seeing "throw" statements as gotos misses the point: you can't really create sp…
>This is a poor argument; the same could be said for almost all control flow statements: if/else
It's technically possible to implement if/else (and loop conditions) with unconditional jumps and offsets, but for reasonable instruction sets (that support conditional jumps) they won't be "goto under the covers."
