On Tue, 17 Sept 2024 at 19:12, Jens Maurer <[email protected]> wrote:
> > > 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. > It gets more complicated for __STDC_VERSION_STDDEF_H__ where the C++ version will not #define unreachable, and for __STDC_VERSION_STDLIB_H__ where the C++ version does not provide ::call_once. Should we prevent declaring the macros so we don't claim to support things that aren't there? > 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
