Rab*_*ter 10 c++ string language-lawyer c++17
在C ++ 17之前，存在多种将整数，浮点数和双精度数与字符串进行转换的方法。例如 std::stringstream，std::to_string，std::atoi，std::stoi，和其他人可能已经被用来完成这些任务。对此，有很多文章讨论了这些方法之间的差异。
但是，C ++ 17现在引入了std::from_chars和std::to_chars。为此，我想知道引入另一种在字符串之间进行转换的方法的原因。
首先，这些新功能比以前的方法具有哪些优势和功能？
不仅如此，这种新的字符串转换方法还有明显的缺点吗？
Sam*_*hik 13
std::stringstream是重量级冠军。它考虑了流的注入区域设置之类的问题，并且其功能涉及诸如在格式化操作期间构造哨兵对象之类的事情，以便处理与异常相关的问题。C ++库中的格式化输入和输出操作以重量轻，速度慢而闻名。
std::to_string的强度小于，std::istringstream但仍返回a std::string，其构造可能涉及动态分配（现代短字符串优化技术不太可能，但仍可能）。而且，在大多数情况下，编译器仍需要在调用站点上生成所有语言，以支持std::string对象（包括其析构函数）。
std::to_chars被设计为具有尽可能小的占地面积。您提供了缓冲区，并且std::to_chars除了以特定的格式将数字值实际格式化为缓冲区之外，几乎没有任何其他特定于区域设置的考虑，而这样做的唯一开销就是确保缓冲区足够大。使用的代码std::to_chars不需要进行任何动态分配。
std::to_chars在格式化选项方面，也更灵活一些，尤其是对于浮点值。std::to_string没有格式选项。
std::from_chars 类似地，它是一个轻量级的解析器，它不需要进行任何动态分配，也不需要牺牲任何电子来处理语言环境问题或流操作的开销。
Nic*_*las 10
to/from_chars被设计为基本字符串转换函数。与替代方案相比，它们具有两个基本优点。
它们的重量轻得多。它们从不分配内存（您可以为它们分配内存）。他们从不抛出异常。他们也从不看区域设置，这也提高了性能。
基本上，它们的设计使得不可能在API级别具有更快的转换功能。
这些函数甚至可以constexpr（不是，尽管我不确定为什么），而更笨重的分配和/或抛出函数则不能。
他们有明确的往返保证。如果将a转换float/double为字符串（没有指定的精度），则需要实现以使其正确，以便采用该确切的字符序列并将其转换回a float/double将产生与二进制相同的值。你不会得到来自担保snprintf，stringstream或to_string/stof。
但是，只有在to_chars和from_chars调用使用相同的实现时，此保证才是好的。因此您不能期望通过互联网将字符串发送到其他可能用不同标准库实现进行编译并获得相同信息的计算机float。但这确实为您提供了计算机上的序列化保证。