operator new
Section: 17.6.3 [new.delete] Status: Resolved Submitter: Stephen Clamage Opened: 2014-02-20 Last modified: 2020-09-06
Priority: 2
View all other issues in [new.delete].
View all issues with Resolved status.
Discussion:
Section 17.6.3 [new.delete] and subsections shows:
void* operator new(std::size_t size); void* operator new[](std::size_t size);
That is, without exception-specifications. (Recall that C++03 specified these functions with throw(std::bad_alloc)
.)
Any other functions defined in the C++ standard library that do not have an exception-specification may throw implementation-defined exceptions unless otherwise specified. An implementation may strengthen this implicit exception-specification by adding an explicit one.
For example, an implementation could provide C++03-compatible declarations of operator new
.
operator new
functions. But how can you write the definition of these functions when
the exception specification can vary among implementations? For example, the declarations
void* operator new(std::size_t size) throw(std::bad_alloc); void* operator new(std::size_t size);
are not compatible.
From what I have been able to determine, gcc has a hack for the special case ofoperator new
to ignore the differences in
(at least) the two cases I show above. But can users expect all compilers to quietly ignore the incompatibility?
The blanket permission to add any explicit exception specification could cause a problem for any user-overridable function.
Different implementations could provide incompatible specifications, making portable code impossible to write.
[2016-03, Jacksonville]
STL: Core changes to remove dynamic exception specs would make this moot
Room: This is on track to be resolved by P0003, or may be moot.
[2016-07, Toronto Thursday night issues processing]
Resolved by P0003.
Proposed resolution: