Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2022-08-15 18:28:02


Andrey Semashev wrote:
> > The semantics are pretty clear when value_type is char, which is what is
> required.
> >
> > It's less clear what should happen when the library calls append or
> > assign with iterators whose value_type is char on something whose
> > value_type is wchar_t, which is what you seem to be doing.
>
> That part is defined by filesystem::path - character code conversion happens.

It's defined, but in my opinion, the semantics are wrong for the intended
use case. The interpretation of paths coming from URLs should not depend
on the current server ANSI code page - that's an implementation detail. You
should be able to move your server to a different Windows installation (or
even to a different OS) and the existing URLs should not suddenly change
meaning.

That's why I think that the only sensible interpretation of paths coming from
URLs is as UTF-8, and for this case, the default filesystem conversion isn't
suitable.

The current MutableString requirements disallow this, as they mandate a
matching value_type of char. This requirement, again in my opinion, is
correct, because if relaxed, people will silently get ANSI code page
dependent conversions, often without realizing it, if they don't develop on
Windows.

_If_ this requirement is relaxed, the library should somehow default to
transcoding from UTF-8 to the value_type, instead of using the ANSI
code page (as with fs::path) or a char to value_type cast (as with
e.g. wstring or u16string.)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk