Question

我很好奇cin.getline和global 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结合？

Answer 1

或多或少。 “他们”可能不希望std::istream以任何方式依赖std::string，可能会最小化coupling。

请注意，std::getline()在<string>模块中定义。

Answer 2

请参阅我对a similar question的回答。它可能是C ++标准委员会的疏忽，但它也可以用依赖关系来解释。如果标准要求std::string标题中<iostream>的函数重载，则需要#include<string>中<iostream>的实施者。这是一个依赖性要求，这将进一步减慢编译需要<iostream>的任何内容 - 即使编译单元本身不需要std::string。

请注意，另一方面<string>标题包含引用std::basic_istream<>和std::basic_ostream<>的函数;但是标准还需要一个名为<iosfwd>的标头，它正向声明所有IO设施，使<string>标头可靠地在编译时快速<iosfwd>标头上。反过来，依赖性的编译要慢得多。

Answer 3

C ++有几个地方   标准委员会并没有真的   优化之间的互动   标准库中的设施。

std :: string及其在库中的使用   就是其中之一。

另一个例子是std :: swap。许多   容器有一个交换成员   函数，但没有std :: swap的重载   供应。同样的道理   的std ::排序。

我希望所有这些小事情都会成真   修正了即将出台的标准。

-Christopher

添加我在其他帖子中找到的这篇文章，因为它似乎相关并接受答案。

为什么std :: cin.getline没有重载方法来获取std :: string？

3 个答案: