Subject: Re: A UTF-8 environment specification; an alternative to assuming UTF-8 based on choice of literal encoding
From: Thiago Macieira (thiago_at_[hidden])
Date: 2021-07-29 17:10:03
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
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
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
SG16 list run by email@example.com