Ping on this. If others think it looks fine, then that would be useful information to have as well.
From: SG10 <[email protected]> On Behalf Of Ben Craig via SG10 Sent: Thursday, August 20, 2020 9:15 AM To: [email protected] Cc: Ben Craig <[email protected]> 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. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2013r1.html#no_macro<https://urldefense.com/v3/__http:/www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2013r1.html*no_macro__;Iw!!FbZ0ZwI3Qg!5LpR-K4A1ryJ44guUu1YbAr1CAAq_TC0cPxNqQ7WXkhx8KTT6qQBlJg5_9jI$> 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 mailing list [email protected] https://lists.isocpp.org/mailman/listinfo.cgi/sg10
