This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
operator newSection: 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: