C++ Logo


Advanced search

Re: [SG16-Unicode] [isocpp-lib] New issue: Are std::format field widths code units, code points, or something else?

From: Victor Zverovich <victor.zverovich_at_[hidden]>
Date: Wed, 11 Sep 2019 17:53:06 -0700
> Is it really too much to ask that it be decoded according to the
locale-specified encoding?

Locale-independence by default is a good property to have. In particular,
it guarantees that std::formatted_size will return the size that is
sufficient for a buffer passed in a subsequent call to std::format_to
regardless of any locale shenanigan that happen in between (possibly in
another thread).

However, one might argue that by explicitly specifying the width a user
opted into encoding-aware behavior for strings (whether determined by
locale or not), so maybe it's not as big of a problem as I initially
thought. There is still a question of how to express the concept of
perceived width in standardese wording. Thiago, do you have any suggestions?

- Victor

On Wed, Sep 11, 2019 at 4:17 PM Thiago Macieira <thiago_at_[hidden]> wrote:

> On Wednesday, 11 September 2019 13:06:39 PDT Tom Honermann wrote:
> > > What can we say about the contents of "result1" and "result2"?
> > > Are they the same? Does it matter what the contents of `s` is?
> >
> > Excellent questions.
> >
> > I really want them to be the same (at least by default, additional
> > opt-in support for locale/encoding sensitive alignment strike me as
> > potentially reasonable assuming identification of compelling use cases).
> > I don't think the contents of `s` should matter (without additional
> opt-in).
> On the other hand, this may be the perfect time to get rid of legacy
> mistakes.
> Any moderately good reason for them to be different should be enough.
> The big issue is understanding how many positions a string like "\xc3\xa9"
> consumes. Is it really too much to ask that it be decoded according to the
> locale-specified encoding?
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel System Software Products
> _______________________________________________
> SG16 Unicode mailing list
> Unicode_at_[hidden]
> http://www.open-std.org/mailman/listinfo/unicode

Received on 2019-09-12 02:53:20