為什么C ++ 03文件流不接受字符串構造函數參數？

Question

為什么以下代碼在C++11編譯而在C++03中不C++03 ？ （包括gcc和cl ）

#include <string>
#include <iostream>
#include <fstream>

int main(int argc, char* argv[]) {
    const std::string t("Hello");
    std::ofstream out(t);
}

為什么C++03流不接受std::string作為構造函數參數？ 這個決定是基於某些事情還是偶然發生的？

Answer 1

使用嚴格符合C ++ 03編譯器編譯時代碼失敗，因為采用std::string的構造函數僅在C ++ 11中添加。

至於這個問題，“這是基於什么聰明”，因為添加了接口，可以推斷，有對於要忽略它沒有技術上的原因。

這是一個額外的便利，因為如果你有一個std::string ，你總是可以調用.c_str()來獲得一個適合與舊接口一起使用的C字符串。 （正如C ++ 11中的文檔所述，采用std::string的構造函數與調用相應的構造函數具有完全相同的效果，該構造函數采用const char* ，並在字符串上調用.c_str() 。）

Answer 2

我記得，幾年前在clc ++上討論了這個問題。而Andrew Koenig（我認為安德魯，無論如何）說它實際上是在一些會議期間提出的， 但接受string的想法很快就與這個想法混為一談了。接受一個wstring ，並從那里變成了關於支持文件名中的國際化字符集的討論，並且......之后不久，整個想法被刪除，因為它已經打開了一大堆蠕蟲沒有人准備交易然后就對了。

Answer 3

他們只是忘記了在C ++ 03中添加string構造函數。 現在已經修好了。 這一次，其他事情都被遺忘了，比如make_unique 。 總有一些人可以做的事情。 C ++ 03也忘了為函數模板指定默認參數，現在包含了這些參數。

編輯：正如@Charles所說，它可能不是字面上的“遺忘”，而是顯然應該存在的東西，但是由於某種原因而沒有被指定。 進一步的例子是由std::next / std::prev ，這是一個很大的緩解， std::to_string和std::stoi/d/ul/ull ，這再次完全合理，但沒有人能夠到達指定它們直到這一輪。 他們之前缺席的原因不一定是深刻的。