exception-specification

c++1z dynamic exception specification error

阅读更多关于 c++1z dynamic exception specification error

问题 I am trying to compile my project with new GCC version 7.2.1 and have a problem with dynamic exception specifications: error: ISO C++1z does not allow dynamic exception specifications MEMORY_ALLOC_OPERATORS(SQLException) The problem is that these errors come from third-party libraries which I do not control. Is there a some way to fix it? As far as I know I can't tell compiler to replace errors with warnings. Using --std=c++14 is not an option because I want to use new features from C++1z.

Exception Specification

阅读更多关于 Exception Specification

问题 I know that this feature will be deprecated in C++0x, but for me as a total novice it seems like a good idea to have it. Could anyone explain to me why isn't a good idea? 回答1: Please see this detailed article by Herb Sutter. He has the most thorough explanation of the problems and short comings of their design. A Pragmatic Look at Exception Specificiations http://www.gotw.ca/publications/mill22.htm 回答2: As far as I understand it, an exception specification means: I wan't you (the compiler) to

How does an exception specification affect virtual destructor overriding?

阅读更多关于 How does an exception specification affect virtual destructor overriding?

问题 The C++ Standard states the following about virtual functions that have exception specifications: If a virtual function has an exception-specification , all declarations, including the definition, of any function that overrides that virtual function in any derived class shall only allow exceptions that are allowed by the exception-specification of the base class virtual function (C++03 §15.4/3). Thus, the following is ill-formed: struct B { virtual void f() throw() { } // allows no exceptions

Why was the old empty throw specification rewritten with a new syntax `noexcept`?

阅读更多关于 Why was the old empty throw specification rewritten with a new syntax `noexcept`?

问题 The title says it all: why did C++ retire the perfectly satisfying, useful, empty throw specification throw() to replace it with another syntax, with the introduction of the new keyword noexcept ? The empty throw specification is the "only throw these enumerated exceptions guarantee" (written throw(X,Y,Z) ), but with zero enumerated exceptions: instead of throwing X , Y or Z (and derived types), you can throw the empty set: that is the guarantee for a function to never throw anything at the

Typeinfo for ocl::CRException

阅读更多关于 Typeinfo for ocl::CRException

问题 I tried to run my C++ program using g++ but am getting following exception: "typeinfo for ocl::CRException" am using ocl namespace containing CRException class.. Please, help me on this. Here is the code where am including OCL classes : #ifndef VOIDSOFT_ADA2_LIND_HH #define VOIDSOFT_ADA2_LIND_HH #include <string> #include <list> #include <queue> #include <map> #include <ocl.h> #include "threaded.hh" using namespace std; using namespace ocl; class circuit; class Lind: public Threaded { public:

Exception specifications when deriving from std::exception in C++11

阅读更多关于 Exception specifications when deriving from std::exception in C++11

问题 I have an exception class as follows: #include <exception> struct InvalidPathException : public std::exception { explicit InvalidPathException() {} const char* what() const; }; const char* InvalidPathException::what() const { return "Path is not valid"; } When compiling under GCC 4.4 with -Wall -std=c++0x error: looser throw specifier for 'virtual const char* InvalidPathException::what() const' error: overriding 'virtual const char* std::exception::what() const throw ()' Quite right, too,

Transitioning to C++11 where destructors are implicitly declared with noexcept

阅读更多关于 Transitioning to C++11 where destructors are implicitly declared with noexcept

问题 In C++11, a destructor without any exception specification is implicitly declared with noexcept , which is a change from C++03. Therefore, a code which used to throw from destructors in C++03 would still compile fine in C++11, but will crash at runtime once it attempts throwing from such a destructor. Since there's no compile-time error with such a code, how could it be safely transitioned to C++11, short of declaring all and every existing destructor in the code base as being noexcept(false)

Exception specifications when deriving from std::exception in C++11

阅读更多关于 Exception specifications when deriving from std::exception in C++11

I have an exception class as follows: #include <exception> struct InvalidPathException : public std::exception { explicit InvalidPathException() {} const char* what() const; }; const char* InvalidPathException::what() const { return "Path is not valid"; } When compiling under GCC 4.4 with -Wall -std=c++0x error: looser throw specifier for 'virtual const char* InvalidPathException::what() const' error: overriding 'virtual const char* std::exception::what() const throw ()' Quite right, too, since I'm overriding std::exception 's what() method that does indeed have a throw() exception specifier.

How can std::runtime_error::runtime_error(const std::string&) meet std::exception's requirement of throw()?

阅读更多关于 How can std::runtime_error::runtime_error(const std::string&) meet std::exception's requirement of throw()?

问题 std::exception requires that its constructor be throw() . Yet std::runtime_error accepts a std::string as its argument, which indicates that it's storing a std::string somewhere. Therefore, an assignment or copy construction has to be going on somewhere. And for std::string , that's not a nothrow operation. How then does runtime_error::runtime_error meet throw() ? (For context, I'm implementing an exception type, and want to store a few std::string s from the call site, and I want to do it

Transitioning to C++11 where destructors are implicitly declared with noexcept

阅读更多关于 Transitioning to C++11 where destructors are implicitly declared with noexcept

In C++11, a destructor without any exception specification is implicitly declared with noexcept , which is a change from C++03. Therefore, a code which used to throw from destructors in C++03 would still compile fine in C++11, but will crash at runtime once it attempts throwing from such a destructor. Since there's no compile-time error with such a code, how could it be safely transitioned to C++11, short of declaring all and every existing destructor in the code base as being noexcept(false) , which would be really over-verbose and intrusive, or inspecting each and every destructor for being