C++ Logo


Advanced search

Subject: Re: Intentionally omitted feature test macro in freestanding operator new (P2013)
From: Ben Craig (ben.craig_at_[hidden])
Date: 2020-08-28 11:14:56

Ping on this. If others think it looks fine, then that would be useful information to have as well.

From: SG10 <sg10-bounces_at_[hidden]> On Behalf Of Ben Craig via SG10
Sent: Thursday, August 20, 2020 9:15 AM
To: sg10_at_[hidden]
Cc: Ben Craig <ben.craig_at_[hidden]>
Subject: [EXTERNAL] [SG10] Intentionally omitted feature test macro in freestanding operator new (P2013)

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.
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.
Does SG10 have any concerns with this approach?

SG10 list run by sg10-owner@lists.isocpp.org