> 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?
libsupc++ and libc++abi are some specific runtime pieces I had in mind with that statement. > If the <new> header declares operator new, it would define the macro. If not, > not. My paper proposes that the declarations for operator new will always be present. The optional aspect is whether the definitions will be present. <new> and <version> can’t really ask libsupc++ and libc++abi if they contain an operator new definition. It means that the information needs to be populated when the toolchain is built, and that the toolchain needs to know enough about the target environment to know whether operator new will be present or not. It’s not a super strong argument, as toolchains will often know exactly what they are targeting, and can make a conservative choice in other circumstances. The lack of a good use case is my stronger argument. It’s still not clear to me whether we would make this a library or a language feature test macro though. From: Jonathan Wakely <[email protected]> Sent: Friday, August 28, 2020 12:40 PM To: [email protected] Cc: Ben Craig <[email protected]> Subject: [EXTERNAL] Re: [SG10] Intentionally omitted feature test macro in freestanding operator new (P2013) On Thu, 20 Aug 2020, 15:15 Ben Craig via SG10, <[email protected]<mailto:[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<https://urldefense.com/v3/__http:/www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2013r1.html*no_macro__;Iw!!FbZ0ZwI3Qg!5M_20wW5k73BOnQQ4rUjjp-GzvRnAE-bu2kIJglmJRs8wiDkODj3eGhF0Gx4$> 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]<mailto:[email protected]> https://lists.isocpp.org/mailman/listinfo.cgi/sg10<https://urldefense.com/v3/__https:/lists.isocpp.org/mailman/listinfo.cgi/sg10__;!!FbZ0ZwI3Qg!5M_20wW5k73BOnQQ4rUjjp-GzvRnAE-bu2kIJglmJRs8wiDkODj3eP9idKA7$>
-- SG10 mailing list [email protected] https://lists.isocpp.org/mailman/listinfo.cgi/sg10
