C++ Logo


Advanced search

Re: [SG16] A UTF-8 environment specification; an alternative to assuming UTF-8 based on choice of literal encoding

From: Thiago Macieira <thiago_at_[hidden]>
Date: Thu, 29 Jul 2021 15:10:03 -0700
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

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

Received on 2021-07-29 17:10:16