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.