On 31/07/2019 17:21, Tom Honermann wrote:
> On 7/31/19 4:27 AM, Niall Douglas wrote:
>> Just fixing up path_view with the feedback from SG16 and LEWG right now.
>>
>> Does anybody have to hand a char8_t implementation for C++ 14? I've
>> currently got a hacky substitute which is really char, but I'd like
>> something better, if somebody already has implemented char_traits et al
>> for older C++.
>
> With both gcc (9.1) and Clang (7, 8) you can enable char8_t with the
> '-fchar8_t' option for earlier standard modes. I'm not sure that is
> helpful for your use case though.

Indeed not. The implementation already auto-detects if the compiler
implements char8_t, and does the right thing. My problem is meaningful
C++ 14 compiler support.

> If you can't use the '-fchar8_t' option, then you have two options:
>
> 1. Introduce a 'char8_t' type alias of 'char' that is for documentation
> purposes only. Obviously, you won't be able to overload based on that.
> 2. Take JeanHeyd's suggestion and introduce a 'char8_t' alias of
> 'unsigned char' and roll your own 'char_traits' and friends.

I ended up doing the right thing, which is a local struct char8_t { char
v; };, and doing the needful to make everything grok that as something
valid.

It's subtly broken of course on older compilers, but it compiles, and it
does invoke a from-utf8 translation like it's supposed to.

FYI Tom you've gained back your `char` constructor, as requested. There
is also a wchar_t constructor, because if you have one, you can't avoid
the other. On Windows, this performs the hideous locale-dependent ANSI
to wchar_t conversion which mangles the input as per Windows ANSI rules.

One can now also specify if the input is zero terminated, as per LEWG
request. No more terminator probing. path_view is now immutable, as
.remove_filename() is no longer mutating.

It should appear in the LLFIO repo by next week, for those interested.
Thanks for the help everyone.

Niall