为什么(i | o)fstream对文件名采用const char*参数?

Set*_*gie 16 c++ history stl

为什么openstd ::(i | o)fstream类的构造函数和方法将文件的名称作为参数以a的形式const char*而不是std::string?似乎STL的创建者想要使用他们所写的内容而不是使用他们编写的类来替换它.

Lig*_*ica 13

string图书馆的一部分是在溪流之后开发的,没有人想过做出明显的修改.

它只是出于政治和时间的现实,他们在发布C++ 98之前从未解决过这个问题,并且没有人因为你总是可以解决它而烦恼.c_str().

C++ 0x修复了这个问题(见27.9.1.6).

欢迎使用C++.


idz*_*idz 6

据我所知,这主要是出于历史原因.ifstream并且ofstream很久以前就存在了std::string.他们当时甚至没有std::回来.


AnT*_*AnT 4

std::string实现了“运行时大小可调整大小的字符串”的概念。这是应该使用此类的时候 - 当您需要一个其大小仅在运行时已知并且也可以在运行时调整大小的字符串时。在您不需要这些功能的情况下,使用这些功能std::string就有点矫枉过正了。显然,该库的作者并不认为他们需要一个运行时可调整大小的字符串来表示文件名,因此他们选择了一个简约的解决方案:他们使用 C 字符串,其中 C 字符串就足够了。这实际上是设计库接口的一个非常好的原则:永远不要需要你并不真正需要的东西。

确实,现在我们经常看到有人鼓励 C++ 程序员std::string在需要字符串时使用任何字符串。他们经常声称经典的 C 字符串应该保留给 C 代码。一般来说,这是一种虚假的哲学。无偿使用相对较重的对象(std::string如 Java)在 Java 等语言中更合适,但在 C++ 中通常是不可接受的。

是的,在某些 C++ 应用程序中可以一直使用 using std::string(“可以用 C++ 编写 Java 程序”),但是在像 C++ 标准库这样的通用低级库中,迫使用户使用std::string如果没有充分的理由(即强加不必要的要求),看起来就不太好。

  • 废话。过去和现在都没有实际理由不这样做;只是在 C++98 发布之前,政治和时间表阻碍了将“std::string”应用于 STL 继承的流功能,并且他们从未费心更新它。我不知道 C++0x 是否解决了这个问题;我不相信确实如此。 (9认同)
  • @Xeo:我同意提供一个重载,从 `std::string` 中获取 `c_str()` 并将其传递给该函数的 C 字符串版本是有意义的。 (2认同)
  • 您经常需要在运行时建立路径名。看起来 `std::string` 是非常合适的。您说“该库的作者并不认为他们需要一个运行时可调整大小的字符串来表示文件名”您对此有参考资料还是这是猜测? (2认同)
  • 我同意这个答案的观点。但据我所知,委员会没有这个理由。它只是被忽视了。 (2认同)