This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.
Section: 16.4.5.6[replacement.functions], 17.6.3[new.delete]Status:CD1Submitter: Matt AusternOpened: 2003-04-24Last modified: 2016-01-28
Priority:Not Prioritized
View all otherissues in [replacement.functions].
View all issues withCD1 status.
Discussion:
The eight basic dynamic memory allocation functions (single-objectand array versions of ::operator new and ::operator delete, in theordinary and nothrow forms) are replaceable. A C++ program mayprovide an alternative definition for any of them, which will be usedin preference to the implementation's definition.
Three different parts of the standard mention requirements onreplacement functions: 16.4.5.6[replacement.functions], 17.6.3.2[new.delete.single]and 17.6.3.3[new.delete.array], and 6.8.6.4[basic.stc.auto].
None of these three places say whether a replacement function may be declared inline. 17.6.3.2[new.delete.single] paragraph 2 specifies a signature for the replacement function, but that's not enough: theinline specifier is not part of a function's signature. One might also reason from 9.2.3[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.
Proposed resolution:
Add a new sentence to the end of 16.4.5.6[replacement.functions] paragraph 3:"The program's definitions shall not be specified asinline.No diagnostic is required."
[Kona: added "no diagnostic is required"]
Rationale:
The fact thatinline isn't mentioned appears to have beennothing more than an oversight. Existing implementations do notpermit inline functions as replacement memory allocation functions.Providing this functionality would be difficult in some cases, and isbelieved to be of limited value.