On Thu, 20 Aug 2020, 15:15 Ben Craig via SG10, <[email protected]> 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 > [email protected] > https://lists.isocpp.org/mailman/listinfo.cgi/sg10 >
-- SG10 mailing list [email protected] https://lists.isocpp.org/mailman/listinfo.cgi/sg10
