On Thursday, 29 July 2021 14:52:48 PDT Corentin Jabot wrote:
> > That may not be the case for "any purpose" C++, especially if we talk
> > about
> > minimal environments found in containers and tiny embedded devices. Only
> > recently did glibc add built-in support for C.UTF-8, as opposed to
> > requiring
> > that a locale be created and installed using localedef or packages. So
> > there's a high probability that those constrained systems will say
> > "C.UTF-8" is not a valid locale and will fall back to "C.ANSI_X3.4-1986".
>
> And I hope this will be less and less true as time goes on: It is unlikely
> that people will look at using C++23 on these system before glibc is
> updated

That's not exactly a safe assumption. It's far easier to update libstdc++ or
libc++ than glibc, especially as those two can be statically-linked against[*]
and glibc is a PITA to statically link to. Like I said, the problem are
containers.

That's exactly what I am doing with an application at work.

[*] be careful about using std::thread or anything thread-related if you
statically-link to both libstdc++ and libpthread.a. It will not work unless
your Linux distro has patched one of them to work with the other.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering