std::ifstream 类的设计

Question

我们这些已经看到 STL 之美的人尝试尽可能多地使用它，并鼓励其他人在我们看到它们的任何地方使用它，使用 原始指针 和 数组时间>。 Scott Meyers 写了一整本关于 STL 的书，标题为 Effective STL。然而，ifstream 的开发人员发生了什么事，他们更喜欢 char* 而不是 std::string。我想知道为什么ifstream::open() 的第一个参数是const char* 类型，而不是const std::string &。请看一下它的签名：

void open(const char * filename, ios_base::openmode mode = ios_base::in );

为什么会这样？为什么不这样：

void open(const string & filename, ios_base::openmode mode = ios_base::in );

这是设计的严重错误吗？还是这个设计是故意的？可能是什么原因？我看不出他们为什么偏爱char* 而不是std::string。请注意，我们仍然可以将char* 传递给采用std::string 的后一个函数。这不是问题！

顺便说一句，我知道ifstream 是一个typedef，所以不要对我的标题发表评论。：P。它看起来很短，这就是我使用它的原因。

实际的类模板是：

template<class _Elem,class _Traits> class basic_ifstream;

Answer 1

因为 IOStream 是在 STL 的一部分集成到标准库之前设计的。字符串类是在那之后制作的。在标准化过程中已经很晚了，修改 IOStream 不被认为是保存。

顺便说一句，作为 C++0X 中微小但方便的更改的一部分，有对这类事情的清理。

Answer 2

My copy of the standard 不同意你的观点。它说这两个都是重载：

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

但是，该标准的副本是该标准的下一版本 C++0x 的草案。

这样做的原因是 iostreams 库早于 std::basic_string，并且因为库设计者不希望有人必须使用 #include <string> 以及所有其他相关的包袱，如果他们不想使用它.

Answer 3

从std::string 获取 C 字符串通常不会比从 C 字符串构造 std::string 更昂贵，因此，鉴于您可能希望将 std::ifstream 与来自的文件名一起使用两者，在界面中使用const char* 的成本并不高。

这是一个严重的设计错误吗？

你不能用当前界面做什么？使用const std::string& 在接口产量方面有什么具体和显着的好处？

在我看来，std::string 重载的真正好处是帮助初学者在第一次尝试一起使用 std::string 和流时轻松搞定。对于经验丰富的 C++ 开发人员而言，与开发代码的其他工作相比，必要时编写 .c_str() 的微不足道的成本可能可以忽略不计。