C++ Logo

sg10

Advanced search

Re: [SG10] Intentionally omitted feature test macro in freestanding operator new (P2013)

From: Jonathan Wakely <cxx_at_[hidden]>
Date: Fri, 28 Aug 2020 18:39:53 +0100
On Thu, 20 Aug 2020, 15:15 Ben Craig via SG10, <sg10_at_[hidden]>
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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg10
>

Received on 2020-08-28 12:43:33