我很好奇cin.getline和全局 getline函数位于不同位置的技术原因。
不简单地为 cin 定义所有这些函数签名的动机是什么：
//THESE TWO EXIST
istream& cin::getline (char* s, streamsize n );
istream& cin::getline (char* s, streamsize n, char delim );
//THESE TWO COULD EXIST
istream& cin::getline (string &s);
istream& cin::getline (string &s, char delim );
是因为可能想要添加其他类型并且他们不想将字符串与 cin 结合吗？
或多或少。“他们”可能不想让std::istream以任何方式依赖std::string ，可能是为了最小化耦合。
注意std::getline()在<string>模块中定义。
请参阅我对类似问题的回答。这可能是 C++ 标准委员会的疏忽，但也可以用依赖关系来解释。如果标准要求std::string在<iostream>标头中重载 for 函数，那么它会要求实现者#include<string>在<iostream>. 这是一个依赖要求，这将进一步减慢编译任何需要<iostream>的东西——即使编译单元本身不需要std::string.
请注意，另一方面，<string>标头具有引用std::basic_istream<>和的函数std::basic_ostream<>；但该标准还需要一个名为的标头，该标头<iosfwd>前向声明所有 IO 设施，使<string>标头依赖于编译时快速<iosfwd>标头。反过来，依赖项的编译速度会慢得多。
有几个地方 C++ 标准委员会并没有真正优化标准库中设施之间的交互。
std::string 及其在库中的使用就是其中之一。
另一个例子是 std::swap。许多容器都有一个交换成员函数，但没有提供 std::swap 的重载。std::sort 也是如此。
我希望所有这些小问题都将在即将发布的标准中得到解决。
添加我在其他线程中找到的这篇文章，因为它似乎相关并接受答案。