std::ifstream 类的设计
我们这些已经看到 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;
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 arrays. Scott Meyers have written a whole book on STL, with title Effective STL. Yet what happened to the developers of ifstream that they preferred char* over std::string. I wonder why the first parameter of ifstream::open() is of type const char*, instead of const std::string &. Please have a look at it's signature:
void open(const char * filename, ios_base::openmode mode = ios_base::in );
Why this? Why not this:
void open(const string & filename, ios_base::openmode mode = ios_base::in );
Is this a serious mistake with the design? Or this design is deliberate? What could be the reason? I don't see any reason why they have preferred char* over std::string. Note we could still pass char* to the latter function that takes std::string. That's not a problem!
By the way, I'm aware that ifstream is a typedef, so no comment on my title.:P. It looks short that is why I used it.
The actual class template is :
template<class _Elem,class _Traits> class basic_ifstream;
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
因为 IOStream 是在 STL 的一部分集成到标准库之前就设计的。之后就制作了字符串类。标准化过程已经相当晚了，修改 IOStream 不被视为保存。
顺便说一句，作为 C++0X 中微小但方便的更改的一部分，对此类内容进行了清理。
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.
我的标准副本不同意你。它说这两个都是重载：
但是，该标准的副本是该标准下一版本 C++0x 的草案。
其原因是
iostreams库早于std::basic_string，并且因为库设计者不希望有人必须#include; 以及所有其他相关行李（如果他们不想使用它）。My copy of the standard disagrees with you. It says both these are overloads:
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
iostreamslibrary predatesstd::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.从
std::string获取 C 字符串通常并不比从 C 字符串构造std::string更昂贵，因此，假设您是可能想要使用std::ifstream以及来自两者的文件名，在接口中使用const char*并不是一个很大的成本。当前界面不能做什么？在接口收益中使用 const std::string& 会有什么具体和显着的好处？
在我看来，std::string 重载的真正好处是可以帮助初学者在第一次尝试同时使用 std::string 和流时轻松地把事情做好。对于经验丰富的 C++ 开发人员来说，与开发代码所需的其他工作相比，在必要时编写
.c_str()的微不足道的成本可能可以忽略不计。It's typically no more expensive to get a C string from a
std::stringthan it is to construct astd::stringfrom a C string so, given that you are likely to want to usestd::ifstreamwith filenames that come from both, using aconst char*in the interface is not a significant cost.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::stringoverload, 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.