为什么std :: fstream类不采用std :: string？

这不是一个设计问题,实际上,虽然看起来像它.(好吧,好吧,这是一个设计问题).我想知道的是为什么C++ std::fstream类不会std::string在构造函数或开放方法中使用它们.每个人都喜欢代码示例:

#include 
#include 
#include 

int main()
{
    std::string filename = "testfile";      
    std::ifstream fin;

    fin.open(filename.c_str()); // Works just fine.
    fin.close();

    //fin.open(filename); // Error: no such method.
    //fin.close();
}

这使我一直处理文件.当然,C++库会std::string尽可能使用？

1> wilhelmtell..：

---

通过使用C字符串,C++ 03 std::fstream类减少了对std::string类的依赖.但是,在C++ 11中,std::fstream该类允许传递一个std::stringfor构造函数参数.

现在,您可能想知道为什么没有从std:stringC字符串到C字符串的透明转换,因此需要C字符串std::string的类仍然可以像std::string需要C字符串的类一样.

原因是这会导致转换周期,这反过来可能会导致问题.例如,假设std::string可以转换为C字符串,以便您可以将std::strings与fstreams 一起使用.假设C字符串也可以转换为std::strings,就像当前标准中的状态一样.现在,请考虑以下事项:

void f(std::string str1, std::string str2);
void f(char* cstr1, char* cstr2);

void g()
{
    char* cstr = "abc";
    std::string str = "def";
    f(cstr, str);  // ERROR:  ambiguous
}

因为你可以在a std::string和c字符串之间进行转换,所以调用f()可以解析为两个f()备选方案中的任何一个,因此是不明确的.解决方案是通过明确一个转换方向来打破转换周期,这是STL选择使用的方式c_str().

---

这种微优化非常愚蠢,因为(1)字符串紧密耦合到语言的任何构造,特别是字符串(这类似于说,我不希望`GMP`依赖于短路),(2) )`char*`是邪恶的,你不应该鼓励用户使用它,如果他们不需要,并且编译时毫秒是值得的,最后(3)他们可以定义``和使用字符串而不依赖它,所以我声称解耦依赖关系根本不是一个正当理由.

2> Christopher..：

---

有几个地方C++标准委员会没有真正优化标准库中设施之间的交互.

std::string 它在图书馆中的使用就是其中之一.

另一个例子是std::swap.许多容器都有一个交换成员函数,但没有提供std :: swap的重载.同样的道理std::sort.

我希望所有这些小事都能在即将出台的标准中修复.

3> Pieter..：

---

也许这是一个安慰:所有fstream都在C++ 0x标准的工作草案中的open(char const*,...)旁边打开了(字符串const&...).(参见例如27.8.1.6的basic_ifstream声明)

因此,当它最终确定并实施时,它将不再让你:)

4> Drealmer..：

---

流IO库已在STL之前添加到标准C++库中.为了不破坏向后兼容性,已决定在添加STL时避免修改IO库,即使这意味着某些问题,例如您提出的问题.