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.

### 2368. Replacing global `operator new`

Section: 17.7.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.7.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)`.)

Section 16.4.6.13 [res.on.exception.handling] the end of paragraph 4 says:

> 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`.

Programmers are allowed to replace these `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 of `operator 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: