任何人都知道为什么C ++标准库'std::string类（或更普遍的std::basic_string类模板）缺少普通的字符串功能，如大写，子串替换和修剪等，与例如，来自Qt的QString类，还是Python字符串？
答案 0 :(得分：5)
我要去捅这个......
模板std::basic_string最初编写并包含在STL中，它代表标准库的“抽象”部分（我们知道它）（容器，迭代器，算法，分配器等） 。这也包括std::string。
请注意STL中绝对没有编码，国际化或语言环境相关的功能。这不是设计目标。
现在我接受前几代人的事情：当C ++标准化时，需要一个全面的标准库。 STL非常适合这种情况，几乎是逐字逐句接管的。仅在稍后添加了<iostream>和<locale>之类的内容。流和字符串之间的笨拙和非常不连贯的界面差异只能证明这种“让我们把它放在一起”的态度。
与许多std工具一样，组件之间的互操作性未得到优化。最重要的是，包含现有C功能的小型C ++函数（如toupper）的简单性已被用作不将其包含在标准库中的原因。
通过标准的下一版本（以及它所包含的库），向后兼容性阻止了任何有用和必要的更改（将区域设置注入std::string功能）。
请注意，这个猜想根本没有解释为什么例如std::trim没有添加字符串和语言环境对象。它试图解释所涉及的背景过程。
既然已经说过了，我完全同意C ++标准库的一般用处是笨重且不完整的。
更新：我被告知我的时间线已颠倒过来：标准库（和iostream）在添加STL之前就已存在。上面的观点仍然有效：STL是复制粘贴的，很少甚至没有集成（简单的例子：直到最近才发现std::basic_istream<T>::open(const std::basic_string<T>&)，由于std::filesystem内容将在下一次迭代中弃用
答案 1 :(得分：3)
无法回答最常见的所有缺失功能，但是......
提到的两个功能，修剪和大写，是与语言环境相关的。它们不仅是字符的功能，还是所使用的编码和语言。
std::string并没有真正解决这个问题。虽然在实践中，每个人都使用带有ASCII定义的空格的Unicode，但这对于定义C ++的标准化过程来说还不够通用。
此类操作是通过流（例如，从std::stringstream读取以去除过多空间）和区域设置对象（例如，通过std::tolower访问）获得的。
答案 2 :(得分：2)
功能不佳？被认为是标准库中的膨胀组件之一。您有一整套算法可以在std::string s上运行，所有标准算法。不要局限于成员函数，界面中的内容远远多于...