This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.
Section: 184.108.40.206 [replacement.functions], 17.6.2 [new.delete] Status: CD1 Submitter: Matt Austern Opened: 2003-04-24 Last modified: 2016-02-10
Priority: Not Prioritized
View all other issues in [replacement.functions].
View all issues with CD1 status.
The eight basic dynamic memory allocation functions (single-object and array versions of ::operator new and ::operator delete, in the ordinary and nothrow forms) are replaceable. A C++ program may provide an alternative definition for any of them, which will be used in preference to the implementation's definition.
Three different parts of the standard mention requirements on replacement functions: 220.127.116.11 [replacement.functions], 18.104.22.168 [new.delete.single] and 22.214.171.124 [new.delete.array], and 126.96.36.199 [basic.stc.auto].
None of these three places say whether a replacement function may be declared inline. 188.8.131.52 [new.delete.single] paragraph 2 specifies a signature for the replacement function, but that's not enough: the inline specifier is not part of a function's signature. One might also reason from 9.1.2 [dcl.fct.spec] paragraph 2, which requires that "an inline function shall be defined in every translation unit in which it is used," but this may not be quite specific enough either. We should either explicitly allow or explicitly forbid inline replacement memory allocation functions.
Add a new sentence to the end of 184.108.40.206 [replacement.functions] paragraph 3: "The program's definitions shall not be specified as inline. No diagnostic is required."
[Kona: added "no diagnostic is required"]
The fact that inline isn't mentioned appears to have been nothing more than an oversight. Existing implementations do not permit inline functions as replacement memory allocation functions. Providing this functionality would be difficult in some cases, and is believed to be of limited value.