Subject: Re: Intentionally omitted feature test macro in freestanding operator new (P2013)
From: Jonathan Wakely (cxx_at_[hidden])
Date: 2020-08-28 12:39:53
On Thu, 20 Aug 2020, 15:15 Ben Craig via SG10, <sg10_at_[hidden]>
> Yesterday, EWGâs telecon requested that I run the feature test macro
> section of my design by SG10 to see if there were any objections.
> Hereâs that text reproduced in the email:
> A feature test macro would be awkward to implement, and would encourage
> code that is more prone to ODR issues than other feature test macros.
> In most toolchains, feature test macros can be exposed directly by the
> compiler (usually for core language features) and by the library (for
> library features). The presence or absence of ::operator new is dictated
> by the runtime though. In some implementations, neither the compiler nor
> the library headers necessarily know detailed information about the
> runtime. This hurdle is not intractable, but it is a hurdle nonetheless.
I don't really understand this, as I'm not sure what "the runtime" means.
The macro would be provided by the <new> header, wouldn't it?
If the <new> header declares operator new, it would define the macro. If
> The most likely usage of such a feature test macro is to conditionally
> define a custom ::operator new iff the implementation did not provide one
> by default. This is dangerous territory, as it encourages libraries to
> provide the one-and-only ::operator new definition. If two such libraries
> do this, then there is an ODR issue.
OK, I am convinced by that argument. Not having a valid use case is good
Does SG10 have any concerns with this approach?
> SG10 mailing list
SG10 list run by email@example.com