On Thu, 20 Aug 2020, 15:15 Ben Craig via SG10, <sg10@lists.isocpp.org> wrote:

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 justification.


Does SG10 have any concerns with this approach?

 

--
SG10 mailing list
SG10@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg10