On 17/09/2024 16.22, Jonathan Wakely wrote:
>
>
> On Tue, 17 Sept 2024 at 15:01, Inbal Levi <sinbal2l_at_[hidden] <mailto:sinbal2l_at_[hidden]>> 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