区分string和bytes，很常见的做法。

【 在 allegro 的大作中提到: 】
: 我大C++就是被这些奇葩特性弄死的.
--
FROM 114.86.95.*

17不是这已经有byte了吗，又弄出一个char8？
【 在 ilovecpp 的大作中提到: 】
: 区分string和bytes，很常见的做法。
--
FROM 171.83.9.*

这帮人都该枪毙.

首先看这个提案的作者说引入char8_t的好处:
https://stackoverflow.com/questions/57402464/is-c20-char8-t-the-same-as-our-old-char/57453713#57453713

To provide a distinct type for UTF-8 character data vs character data with an encoding that is either locale dependent or that requires separate specification.

To enable overloading for ordinary string literals vs UTF-8 string literals (since they may have different encodings).

To ensure an unsigned type for UTF-8 data (whether char is signed or unsigned is implementation defined).

To enable better performance via a non-aliasing type; optimizers can better optimize types that do not alias other types.

然后,我目前看到的艹的地方(我只用了一晚上char8串):
1. 没有任何方法可以把一个char的串转化为char8_t的串,除非你一个一个char的赋值一次.
reinterpret_cast<const char   *>(u8"text"); // Ok.
reinterpret_cast<const char8_t*>("text");   // Undefined behavior.

2. char8串无法输出到stream.
3. std::format不支持char8串.

于是对于以前const char *的代码:
a). 考虑全用const char *, 这就需要把char8串一律转化为char串,面对的问题:
1. 你不能在constexpr函数中用char8串.
2. 你可能失去printf格式检查,因为你的char8的format格式现在需要一个转换.
3. 你不知道当你强制转换为char串后,接口内部是否仍然用utf8处理了你的串.

b). 考虑全用const char8_t *:
1. 不可能,因为无论如何都会break strict-aliasing.
2. 你可能会调用其他api,他们目前只提供std::string/const char *的接口.

艹

【 在 libgcc 的大作中提到: 】
: 17不是这已经有byte了吗，又弄出一个char8？
--
FROM 158.140.1.*

你们都用这么新的标准了啊
我一般等落地3年后再去研究的
【 在 allegro 的大作中提到: 】
: 这帮人都该枪毙.
: 首先看这个提案的作者说引入char8_t的好处:
: https://stackoverflow.com/questions/57402464/is-c20-char8-t-the-same-as-our-old-char/57453713#57453713
: ...................
--
FROM 171.83.9.*

还好还好，C++20出来，到2040年应该可以投入商用了……让你猴急现在就要用！  
  
【 在 allegro () 的大作中提到: 】
: 这帮人都该枪毙.
:
: 首先看这个提案的作者说引入char8_t的好处:
: https://stackoverflow.com/questions/57402464/is-c20-char8-t-the-same-as-our-old-char/57453713#57453713
--
FROM 138.19.103.*