C++ Logo


Advanced search

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.
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2013r1.html#no_macro
> 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
not, not.

> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg10

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