On Monday, 1 March 2021 14:31:09 PST Ville Voutilainen wrote: > On Tue, 2 Mar 2021 at 00:21, Thiago Macieira <thiago.macie...@intel.com> wrote: > > But the code I posted, if people are careful to use write like I did, > > would > > allow us to have the experimental "we're not sure this is right" > > implementation of atomic waits, latches, barriers and semaphores right > > now. > > The code assumes that as soon as __cplusplus bumps and a header is > present, things > are stable.
Not exactly. Re-posting the code for reference: #if __cplusplus >= 202002L && __has_include(<latch>) # include <latch> #endif #if __cpp_lib_latch < 201907L # error "Please upgrade your Standard Library" #endif The first section simply assumes that <latch> can be #included. The __cplusplus check is necessary because MSVC STL's headers are present but can't be #include'd otherwise (they cause #error). It's the second check that is authoritative. > I don't think that's a safe assumption to make. > Furthermore, the second #if > tries to check a feature-testing macro without including either the > corresponding header > or <version>. That doesn't work. You need to either include <version> > and check a macro, > or check that <latch> exists, then include <latch> and then check the macro. <version> would work, but why can't you check the macro anyway? It may trigger a warning with GCC's -Wundef, but it's just a warning. The preprocessor is defined to replace any undefined identifier with 0. If you want to avoid the warning, you could write: #if defined(__cpp_lib_latch) && __cpp_lib_latch < 201907L Is there anything I'm not seeing? > But other than that, sure, as QoI, vendors could already provide the > standard macros with > numbers that are lower than the standard ever specified. Going > forward, if existing facilities > are changed, this stops working because now you'd have to track the > WPs to see which > values are "vendor-bogus". I find it better to just change the macros > whose facilities changed > during a standard cycle, and in those cases bump the IS macro, that'll > then work going forward. > In the meanwhile, when vendors can, they could use the technique you > describe, but that's > barely worth proposing as an SG10 guideline because they would've > needed to do it already, but didn't. :P I am not opposed to that. Your solution is better. But this solution is less work on the standard and still works, even if it creates a little more work on the users of said features. It's not unsurmountable, since we often need to check which C++ standard edition it came with anyway. So it doesn't matter what value it assumes: we'll be consulting a table anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering
