On 1/26/24 7:29 AM, Jonathan Wakely via Liaison wrote:
>
>
> On Fri, 26 Jan 2024 at 11:34, Nina Dinka Ranns via Liaison
> <liaison_at_[hidden]> wrote:
>
> Hi all,
>
> with the release of C23, the C++ standard needs to be updated too.
> We're looking for a volunteer or a group of volunteers to help
> with that effort. I'm cheekily adding the people who did this for
> C11 in hope of getting them interested in doing the same thing
> again. :)
>
>
> Some notes on the changes to the standard library in C2x, taken from
> https://en.cppreference.com/w/c/23 (I'm ignoring the core language
> changes, that's somebody else's job ;-)
>
> Removed from C:
>
> - Support for calling realloc() with zero size (the behavior becomes
> undefined)
>
> This will affect C++ as we just incorporate realloc by reference.
> Seems OK, it just needs to be documented in Clause C.
>
> - __alignof_is_defined and __alignas_is_defined
>
> We already deprecated the latter ready to remove it when we do the
> rebase. For some reason C++ never had the former (probably an error),
> so we're adding it and deprecating it via an LWG issue:
> https://cplusplus.github.io/LWG/issue4036
>
> - static_assert is not provided as a macro defined in <assert.h>
> (becomes a keyword)
> - thread_local is not provided as a macro defined in <threads.h>
> (becomes a keyword)
>
> These don't affect C++, we never had those macros (and don't have
> <threads.h> at all).
>
> Deprecated in C:
>
> - <stdnoreturn.h>
>
> Not present in C++ at all.
>
> - Old feature-test macros
> __STDC_IEC_559__
> __STDC_IEC_559_COMPLEX__
>
> Not present in C++.
>
> - asctime()
> - ctime()
>
> We incorporate these by reference, but C++ already provides other
> facilities for formatting times without depending on global state.
>
> - DECIMAL_DIG (use the appropriate type-specific macro
> (FLT_DECIMAL_DIG, etc) instead)
> - Definition of following numeric limit macros in <math.h> (they
> should be used via <float.h>)
> INFINITY
> DEC_INFINITY
> NAN
> DEC_NAN
>
> We'll pick up these changes by reference too. Seems fine for them to
> be deprecated in C++, we already have the FLT_DECIMAL_DIG,
> DBL_DECIMAL_DIG etc. macros, as well as std::numeric_limits.
>
> __bool_true_false_are_defined
>
> This is already deprecated in C++23, ready to remove it at a later date.
>
> - New library headers <stdbit.h> and <stdckdint.h>.
> The former would come along with _BitInt if we add that to the core
> language, and should be explicitly noted as absent otherwise.
> The latter provides extremely useful functionality, but we probably
> want a more C++-like interface, and maybe add them to <numeric>
> alongside the new saturation arithmetic functions. 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. I'll raise this with LEWG.
>
> - decimal floating-point math functions
> We don't have DFP (there was a TS but it's outdated and needs a revision).

What, if anything, needs to be done with regard to the printf()
specifiers for the _DecimalNN types in C++? I guess an attempt to use
them is just UB according to the standard since the corresponding
builtin types don't exist? Note that, even if we were to standardize the
std::decimalNN types from the TS, they still couldn't be passed as
variadic arguments (I hope that a new proposal to include DFP support in
C++ will follow the precedent set by the extended floating point types
and just specify alternate names instead of completely different and
incompatible library types).

>
> - floating-point formatting functions
> Redundant with std::to_chars and std::to_string, but I see no harm in
> incorporating them by reference.
>
> - library support for UTF-8
> We already have char8_t (and its atomic cousin). mbrtoc8 and c8rtomb
> are better than nothing, but being tied to the global C locale makes
> them of limited use in C++. We really want something that works with
> the encoding of an arbitrary std::locale (or at least a ::locale_t, or
> just POSIX iconv) not dependent on global state. I've emailed SG16
> about the two new functions.

mbrtoc8 and c8rtomb are already present in the std namespace as of C++20.

What I think we need is:

 1. A way to identify the encoding associated with an arbitrary locale.
 2. A general transcoding facility that is implementable as a light
    wrapper over iconv(), MultiByteToWideChar() and
    WideCharToMultiType(), or ICU's converters
    <https://unicode-org.github.io/icu/userguide/conversion/converters.html>.

Tom.

>
> - memset_explicit
> I assume we want this.
>
> - POSIX functions memccpy, strdup, strndup, gmtime_r, localtime_r,
> extensions for strftime and wcsftime.
> I assume we want these too (the time ones are improvements on what's
> in C today, but still less flexible than std::chrono).
>
> - extensions for fscanf and fprintf function families.
> You can already do all of this with iostreams and std::to_string and
> std::sto* and there's a proposal for std::scan, so meh. But we might
> as well have them.
>
> - timespec_getres
> The timespec_get API is difficult to reconcile with POSIX clock APIs,
> unfortunately: https://www.openwall.com/lists/libc-coord/2023/04/25/2
> I doubt anybody cares about this in C++. I doubt most people even know
> it exists. I'm OK if it we take it as long as people continue to be
> unaware it exists.
>
> - Macro constants for width of integer types
> - Additional numeric limit macros for floating-point types
> We already have std::numeric_limits for it, but I still use these (but
> maybe that's because I'm implementing a stdlib and for normal users
> std::numeric_limits is the right choice). We might as well have them.
>
> - Library version-test macros
> I don't think we want these, we have a different way of doing
> feature-test macros. We might want some new __cpp_lib_xxx macros that
> depend on the underlying libc ones though.
>
>
>
>
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription:https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post:http://lists.isocpp.org/liaison/2024/01/1337.php