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

发布于 2024-10-01 01:17:54 字数 585 浏览 1 评论 0原文

我很好奇 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 结合起来吗?

I'm curious about the technical reason for cin.getline and the global getline function being in different places.

What was the motivation for not simply defining all these function signatures for 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 );

Was it because other types may want to be added and they didn't want to marry the string to cin?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

萌无敌 2024-10-08 01:17:55

请参阅我对类似问题的回答。这可能是 C++ 标准委员会的疏忽,但也可以用依赖性问题来解释。如果标准要求 标头中的 std::string 函数重载,那么它将要求实现者 #include 中。这是一个依赖项要求,这会进一步减慢编译任何需要 的内容——即使编译单元本身不需要 std::string

请注意,另一方面 标头具有引用 std::basic_istream<>std::basic_ostream的函数。 >;但该标准还需要一个名为 的标头,它向前声明所有 IO 设施,使 标头依赖于编译时的快速 标头。相反的依赖关系编译起来会慢得多。

See my answer for a similar question. It might be an oversight by the C++ Standard committee, but it can also be explained with dependency concerns. If the standard would require function overloads for std::string in the <iostream> header then it would require implementers to #include<string> in <iostream>. That's a dependency requirement, which would further slow down compiling anything that requires <iostream> -- even if a compilation unit doesn't itself need std::string.

Do note that on the other hand the <string> header has functions that take a reference to std::basic_istream<> and std::basic_ostream<>; but the standard also requires a header named <iosfwd> which forward-declares all IO facilities, making the <string> header dependable on the compile-time fast <iosfwd> header. A dependency the other way around would be much slower to compile.

无所谓啦 2024-10-08 01:17:55

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

请注意, std::getline() 是在 中定义的; 模块。

More or less. "They" probably didn't want to have std::istream depend on std::string in any way, probably to minimize coupling.

Note that std::getline() is defined in the <string> module.

蒲公英的约定 2024-10-08 01:17:55

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

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

另一个例子是 std::swap。许多
容器有一个交换成员
函数,但没有 std::swap 的重载
已提供。同样适用于
std::排序。

我希望所有这些小事都会
已在即将发布的标准中修复。

-Christopher

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

There are several places where the C++
standard committee did not really
optimize the interaction between
facilities in the standard library.

std::string and its use in the library
is one of these.

One other example is std::swap. Many
containers have a swap member
function, but no overload of std::swap
is supplied. The same goes for
std::sort.

I hope all these small things will be
fixed in the upcoming standard.

-Christopher

Adding this post I found in that other thread because it seems relevant and accepting an answer.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文