exception-specification


c++1z dynamic exception specification error

ε祈祈猫儿з 提交于 2020-01-01 04:19:06
问题 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

旧时模样 提交于 2019-12-21 07:13:53
问题 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?

那年仲夏 提交于 2019-12-17 16:07:11
问题 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`?

别来无恙 提交于 2019-12-13 20:12:18
问题 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

落花浮王杯 提交于 2019-12-12 02:24:16
问题 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

廉价感情. 提交于 2019-12-05 19:00:00
问题 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

六眼飞鱼酱① 提交于 2019-12-04 17:42:57
问题 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

空扰寡人 提交于 2019-12-04 02:52:52
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()?

|▌冷眼眸甩不掉的悲伤 提交于 2019-12-03 15:33:33
问题 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

浪尽此生 提交于 2019-12-03 12:37:56
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

工具导航Map