4 ms·

I'm not in a position to advise people on what they should or shouldn't do, I am ignorant of a great many things. Until I wrap my head around the following, I w

I'm not in a position to advise people on what they should or shouldn't do, I am ignorant of a great many things. Until I wrap my head around the following, I won't be writing C++ unless I have to: http://en.cppreference.com/w/cpp/language/except_spec http://en.cppreference.com/w/cpp/language/except_spec The fact this is deprecated in c++11 is my personal pet peeve. I can't reason about what the impact is without putting it in to practice, but given that exception safe C++ can be hard to write and it's deprecated does that mean it's going away in C++14 and what are the implications of that? The throw() specifier (counter intuitively meaning 'should not throw anything') is everywhere! If it turns out that all the advocacy for using exceptions has resulted in written code that uses deprecated conventions and requires maintenance and re-understanding, then I will be very very disappointed.

cpeterso 13y ago
C++ exceptions are not checked at compile-time like Java exceptions (excluding Java's unchecked RuntimeExceptions). The C++ throw() specifier is a run-time check that aborts your program if an exception not listed in the throw() specifier escapes the function. C++'s design combines the worst of checked and unchecked exceptions and adds some additional run-time overhead for good measure. Writing exception-safe C++ code is essentially impractical for large C++ programs that include C libraries unless you write your own RAII classes for everything. But then your C++ code is littered with unreadable std::shared_ptr<whatever> everywhere. If C++11 had adopted some Rust-like shorthand syntax for std::shared_ptr and std::unique_ptr, it might actually be palatable.
- eliasmacpherson 13y ago
  "C++ exceptions are not checked at compile-time" are you sure about that [1][2], this is what throw() was deprecated for: [1]http://en.cppreference.com/w/cpp/language/noexcept http://en.cppreference.com/w/cpp/language/noexcept [2]http://en.cppreference.com/w/cpp/language/noexcept_spec http://en.cppreference.com/w/cpp/language/noexcept_spec Unless I am mistaken, on 32bit platforms exceptions incur a runtime overhead but for 64bit zero cost exceptions were developed, and only incur overhead if they are triggered [3] [3] http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Exception-Handling-Control.html http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Exception-Handlin... I think that any calls to the C library can be handled as followed in an exception safe manner unless I misunderstand you: EDIT:( I misunderstood you, you meant wrapping resources, what follows is nonsense as a C library isn't going to throw any exception) void library_function_wrapper() { try { library_function(); } catch(...) { } }
  - cpeterso 13y ago
    I'm not familiar with C++11's noexcept specifier, but the throw() example from [1] shows how throwing a W object is caught at run-time instead of compile-time. I think compile-time exception checking is infeasible because C++ functions without a throw() specifier might throw any exception, so the caller can't actually check at compile-time what exceptions might be thrown. void f() throw(X, Y) { int n = 0; if (n) throw X(); // OK if (n) throw Z(); // also OK throw W(); // will call std::unexpected() at run-time, not a compile-time error } [1] http://en.cppreference.com/w/cpp/language/except_spec http://en.cppreference.com/w/cpp/language/except_spec

cpeterso 13y ago

C++ exceptions are not checked at compile-time like Java exceptions (excluding Java's unchecked RuntimeExceptions). The C++ throw() specifier is a run-time check that aborts your program if an exception not listed in the throw() specifier escapes the function. C++'s design combines the worst of checked and unchecked exceptions and adds some additional run-time overhead for good measure. Writing exception-safe C++ code is essentially impractical for large C++ programs that include C libraries unless you write your own RAII classes for everything. But then your C++ code is littered with unreadable std::shared_ptr<whatever> everywhere. If C++11 had adopted some Rust-like shorthand syntax for std::shared_ptr and std::unique_ptr, it might actually be palatable.

eliasmacpherson 13y ago
"C++ exceptions are not checked at compile-time" are you sure about that [1][2], this is what throw() was deprecated for: [1]http://en.cppreference.com/w/cpp/language/noexcept http://en.cppreference.com/w/cpp/language/noexcept [2]http://en.cppreference.com/w/cpp/language/noexcept_spec http://en.cppreference.com/w/cpp/language/noexcept_spec Unless I am mistaken, on 32bit platforms exceptions incur a runtime overhead but for 64bit zero cost exceptions were developed, and only incur overhead if they are triggered [3] [3] http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Exception-Handling-Control.html http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Exception-Handlin... I think that any calls to the C library can be handled as followed in an exception safe manner unless I misunderstand you: EDIT:( I misunderstood you, you meant wrapping resources, what follows is nonsense as a C library isn't going to throw any exception) void library_function_wrapper() { try { library_function(); } catch(...) { } }
- cpeterso 13y ago
  I'm not familiar with C++11's noexcept specifier, but the throw() example from [1] shows how throwing a W object is caught at run-time instead of compile-time. I think compile-time exception checking is infeasible because C++ functions without a throw() specifier might throw any exception, so the caller can't actually check at compile-time what exceptions might be thrown. void f() throw(X, Y) { int n = 0; if (n) throw X(); // OK if (n) throw Z(); // also OK throw W(); // will call std::unexpected() at run-time, not a compile-time error } [1] http://en.cppreference.com/w/cpp/language/except_spec http://en.cppreference.com/w/cpp/language/except_spec