Design of std::ifstream class

Question

Those of us who have seen the beauty of STL try to use it as much as possible, and also encourage others to use it wherever we see them using raw pointers and a

Answer 1

It's typically no more expensive to get a C string from a std::string than it is to construct a std::string from a C string so, given that you are likely to want to use std::ifstream with filenames that come from both, using a const char* in the interface is not a significant cost.

Is this a serious mistake with the design?

What can't you do with the current interface? What concrete and significant benefit would taking a const std::string& in the interface yield?

The real benefit of a std::string overload, as I see it, is as a help to beginners making it easy to get things right when first attempting to use std::string and streams together. To experienced C++ developers the trivial cost of writing .c_str() when necessary is likely to be negligible compared to rest of the effort that goes into developing code.

Answer 2

Because IOStream was designed way before part of the STL was integrated in the standard library. And the string class was made after that. It was pretty late in the standardization process and modifying IOStream was not considered save.

BTW, as part of the minor but convenient changes in C++0X is there was a clean up of this kind of things.

Answer 3

My copy of the standard disagrees with you. It says both these are overloads:

void open(const char* s, ios_base::openmode mode = ios_base::in);
void open(const string& s, ios_base::openmode mode = ios_base::in);

However, that copy of the standard is a draft of the next version of the standard, C++0x.

The reason for this is that the iostreams library predates std::basic_string, and because the library designers didn't want someone to have to #include <string> and all it's other associated baggage if they didn't want to use it.