问题标签 [char-traits]

考虑以下constexpr函数，static_strcmp它使用 C++17 的constexpr char_traits::compare函数：

godbolt显示这在编译时得到评估，并优化为：

constexpr从中删除bool result：

如果我们删除constexprfrom constexpr bool result，现在调用不再优化。

Godbolt显示我们现在调用memcmp：

添加短路length检查：

如果我们在调用之前char_traits::length先比较in 中的两个参数，而没有on ，则调用会再次被优化掉。static_strcmp char_traits::compare constexprbool result

Godbolt显示我们回到了被优化的调用：

• 为什么constexpr从初始调用中删除static_strcmp会导致持续评估失败？
• 很明显，即使没有 constexpr，调用也会在编译时进行评估，那么为什么在第一个版本中char_traits::length没有相同的行为呢？constexprstatic_strcmp

根据GCC 8 Release Note，现在可以在常量表达式中使用std::char_traits<char>and ：std::char_traits<wchar_t>

• 改进了对 C++17 的实验性支持，包括以下功能：
  • std::char_traits 和 std::char_traits<wchar_t> 可用于常量表达式。

std::char_traits<char>我在这里的理解是在 GCC 8 之前你不能在常量表达式中使用。

但是，以下代码可以很好地与GCC 7.5一起编译：

那么，在 GCC 8 之前是否可以在常量表达式中使用 std::char_traits ？还是我错过了什么？

尝试编译此代码时：

编译器会警告我从调用到unsigned char的oh-not-so-healthy 转换到. 事实上，它只是一个 typedef ，人们可能会认为使用而不是允许他们在没有警告的情况下编译上面的代码，正如预期的模板类型指针一样。charwrite()std::fstreamstd::basic_fstream<char>std::basic_fstream<uint8_t>write()

这当然可行，但又出现了另一个问题。即使这段代码编译得很好：

write()即使以前的版本正在运行，它现在也会在调用 时失败（忽略编译器警告）。我花了一段时间来确定标准 C++ 库代码中异常是从哪里引发的，但我仍然不太明白这里的情况。它看起来std::basic_fstream使用了一些字符编码机制，并且由于定义了一个 forchar但没有定义 for unsigned char，因此文件流在尝试使用“错误”字符数据类型时会默默地失败......至少我是这么看的。

但这也是我不明白的。不需要任何字符编码。我什至不以文本模式打开文件，我想处理二进制数据。这就是为什么我使用类型数组而uint8_t不是 char 的原因，使用这种数据类型而不是普通的 old 感觉更自然char。但在我决定放弃uint8_t数据类型并接受使用char缓冲区或开始使用byte定义为 的自定义数据类型的数组之前char，我想问两个问题：

1. 究竟是什么机制阻止我使用无符号字符数据类型？它真的与字符编码有关，还是有其他用途？为什么文件流适用于有符号字符数据类型，但不适用于无符号数据类型？
2. 假设我仍然想使用std::basic_fstream<uint8_t>，无论它多么（不）合理 - 有没有办法实现这一点？

问题如何正确使用std::cin.get()and的返回值std::cin.peek()？让我想知道是否可以保证

对于所有char有效值c。

这出现在很多地方。例如，istream::peek调用streambuf::sgetc，用于to_int_type将char值转换为int_type. 现在，std::cin.peek() == '\n'真的意味着下一个字符是\n？

以下是我的分析。让我们从[char.traits.require]和[char.traits.specializations.char]收集碎片：

1. 对于每个int值e，to_char_type(e)返回

   • c, 如果​eq_­int_­type(e, ​to_­int_­type(c))对于一些c;

   • 其他一些未指定的值。

2. 对于每对int值e和f，eq_­int_­type(e, f)返回

   • eq(c, d), 如果e == to_int_type(c)和f == to_int_type(d)对于一些c和d;

   • true, 如果e == eof()和f == eof();

   • false, 如果e == eof()异f == eof()或;

   • 否则未指定。

3. eof()返回一个值e，使得!eq_int_type(e, to_int_type(c))所有c.

4. eq(c, d)当且(unsigned char) c == (unsigned char) d当

现在，考虑这个假设的实现：（语法简化）

注意

• （属性1）从unsigned char到的转换int是保值的；

• （属性 2）从charto的转换unsigned char是双射的。

现在让我们验证要求：

1. 对于每一个int值e，如果​eq_­int_­type(e, ​to_­int_­type(c))对于一些c，那么e == int(c) + 1。因此，to_char_type(e) == char(int(c)) == c。

2. 对于每对int值eand f，如果e == to_int_type(c)和f == to_int_type(d)对于一些cand d，则当且eq_int_type(e, f)当当int(c) + 1 == int(d) + 1当c == d（通过属性 1）。EOF 案例也很容易验证。

3. 对于每个char值c, int(c) >= -128, 所以int(c) + 1 != EOF。因此，!eq_int_type(eof(), to_int_type(c))。

4. 对于每对char值c和d，eq(c, d)当且仅当(unsigned char) c == (unsigned char d)（通过属性 2）。

这是否意味着这个实现符合要求，因此std::cin.peek() == '\n'没有做它应该做的事情？我在分析中遗漏了什么吗？

我正在使用 Linux 系统，我认为标准 Linuxstd::string支持 Unicode 和 ASCII 字符。所以，我想std::string在我的代码中使用，但我从应用程序接收格式为std::basic_string<unsigned short int, TRAIT_CLASS>（支持 Windows 和 Linux）的字符串。TRAITS_CLASS如下：

如何std::string为上述std::basic_string模板分配法线？喜欢：

如果无法分配，我该如何使用上述basic_string模板？