On 17/09/2024 16.22, Jonathan Wakely wrote: > > > On Tue, 17 Sept 2024 at 15:01, Inbal Levi <[email protected] > <mailto:[email protected]>> wrote: > > Thank you, Jonathan! > Adding chair for today (Fabio) and co-chairs as FYI. > > > We also haven't got a decision on what to do with the new math and > numerics stuff in C23. > True. I see the new utils are not added as part of your paper, so we can > move forward with the paper today. We'll get back to that when we have SG4's > input. > I'll ping Mattias (I thought I did, but must have forgotten to..) > > > LEWG should decide whether to incorporate <stdckint.h> as-is if we're > not going to have something like it in time for C++26 (0). (from document) > > C++ has no equivalent currently, but we probably don’t want > type-generic macros like C has. (from P3348R0) > > For stdckdint.h we're not going to use the C header, so should not > define the C macro. > > I was referring to this as an open question, as it wasn't voted on yet, > but I know your paper doesn't propose adding it. > I (personally) agree that having this in C++ shape is better (and we > might need a follow-up paper for that), and that it's probably better to have > nothing in 26 than adding the C shape. > Might be worth bringing up in LEWG (and if they do ask to add the C shape > as well, then figure out what to do). > > > P3370 already has the macro, so I don't think we need to figure out what to > do if LEWG do want it. > > I assume the motivation for adding it was so mixed C/C++ headers can use the > same macro to check for the features whether the header is compiled as C or > C++/
Exactly. C-style code being compiled as C++ might want to do #ifdef __something from the C standard, so the corresponding macro should be defined if we provide that functionality with the C interface. C++ feature-test macros should not be added for anything we take 1:1 from C. Jens -- SG10 mailing list [email protected] https://lists.isocpp.org/mailman/listinfo.cgi/sg10
