Why does std::cin.getline not have an oveloaded method to take std::string?
Asked Answered
D

3

5

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?

Doable answered 5/11, 2010 at 20:58 Comment(3)
possible duplicate of Why don't the std::fstream classes take a std::string?Subsidence
@wilhelmtell: This seems like a completely different question.Nunciata
@Nunciata the question is very similar, even if the names are different. The answer should be (nearly) identical.Subsidence
S
4

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.

Subsidence answered 5/11, 2010 at 21:20 Comment(0)
G
4

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.

Gaiser answered 5/11, 2010 at 21:15 Comment(0)
S
4

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.

Subsidence answered 5/11, 2010 at 21:20 Comment(0)
D
0

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.

Doable answered 5/11, 2010 at 22:11 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.