On 22/03/2025 19.27, Daniil Rozanov via Std-Discussion wrote:
> I've heard many times at all sorts of conferences that locales are
> broken, that developers write their implementations without locales, and
> that using std::locale now is an outdated practice. In this regard, I
> have a few questions about it.
>
> 1. What exactly is wrong with locales? Can you just give me link to some article
> or paper with explanation about it.

It seems to me that locales address a random corner of the problem space,
and is neither here nor there.

Check out https://icu.unicode.org/ for a more comprehensive solution.

> 2. In that regard, is everything okay with all kinds of std::streambuf
> and std::stream? Suppose I write a new library that supports c++11 and
> later. Should I support streams interface (which implicitly uses locales
> (or I can reimplement whis??)) or is it better to imlement any different
> interface for I/O operations? I mean, doesn't SG16 do things that will
> replace std::codecvt. Maybe there is more modern way to support I/O.

> 3. Is it ok for new code to have I/O classes derived from basic_ios?
> More specifically, I want to make some wrap on C library with it's own
> I/O, which is quite similar to linux api (read, write, getch, etc). Is
> stream interface still common for that?

It's your code, so by definition it's ok to do what you want to do.

If std::locale provides the features you want, and iostreams does what
you want, by all means, use it: it's there to be used.

If, however, you feel the std::streambuf approach doesn't support
e.g. mmap-style I/O adequately for your needs
(see https://www.kernel.org/doc/html/latest/networking/af_xdp.html )
then maybe you want to write something else.

Jens