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

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.