Entwurf von std :: ifstream Klasse

Question

Diejenigen von uns, die Schönheit der STL Versuch gesehen haben, so viel wie möglich zu verwenden, und auch andere dazu ermutigen, es zu benutzen, wo immer wir sie mit rohen Zeiger und Arrays sehen. Scott Meyers haben ein ganzes Buch über STL geschrieben, mit Titel Effective STL. Doch was passierte mit den Entwicklern von ifstream, die bevorzugten char* über std::string. Ich frage mich, warum der erste Parameter von ifstream::open() vom Typ const char* statt const std::string & ist. Bitte sehen Sie sich die Unterschrift an:

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

Warum das? Warum nicht diese:

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

Ist dies ein schwerwiegender Fehler mit dem Design? Oder dieses Design ist bewusst? Was könnte der Grund sein? Ich sehe keinen Grund, warum sie char* über std::string bevorzugt haben. Beachten Sie, dass wir char* noch an die letzte Funktion übergeben können, die std::string übernimmt. Das ist kein Problem!

Übrigens, ich bin mir bewusst, dass ifstream ist ein typedef, also kein Kommentar zu meinem title.:P. Es sieht kurz aus, deshalb habe ich es benutzt.

Die tatsächliche Klassenvorlage ist:

template<class _Elem,class _Traits> class basic_ifstream; 

Answer 1

My copy of the standard stimmt nicht mit Ihnen überein. Er sagt, diese beiden sind Überlastungen:

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

jedoch, dass Kopie des Standards ist ein Entwurf für die nächste Version des Standards, C++ 0x.

Der Grund dafür ist, dass die iostreams Bibliothek std::basic_string früher, und weil die Bibliothek Designer nicht jemand #include <string> haben wollten und alles es anderes zugehöriges Gepäck, wenn sie nicht benutzen wollten.

Answer 2

Da Iostream entwickelt wurde, bevor ein Teil der STL in der Standardbibliothek integriert wurde. Und die String-Klasse wurde danach gemacht. Es war ziemlich spät im Standardisierungsprozess und das Ändern von IOStream wurde nicht als sicher angesehen.

BTW, als Teil der kleinen aber praktischen Änderungen in C++ 0X gab es eine Bereinigung dieser Art von Dingen.

Answer 3

Es ist in der Regel nicht teurer ein C-String aus einem std::string zu bekommen, als es ein std::string aus einer C-String zu erstellen ist so gegeben, dass Sie wahrscheinlich verwenden std::ifstream mit Dateinamen wollen, die von beiden kommen, unter Verwendung eines const char* in der Schnittstelle ist keine erhebliche Kosten.

Ist das ein schwerwiegender Fehler beim Design?

Was können Sie mit der aktuellen Schnittstelle nicht tun? Welchen konkreten und signifikanten Nutzen würde eine const std::string& in der Schnittstelle bringen?

Der eigentliche Vorteil einer std::string Überlastung, wie ich es sehe, ist als eine Hilfe für Anfänger Recht es leicht, die Dinge zu bekommen, wenn ersten std :: string zu verwenden versuchen und zusammen Ströme. Für erfahrene C++ - Entwickler sind die trivialen Kosten für das Schreiben von .c_str() bei Bedarf wahrscheinlich vernachlässigbar im Vergleich zu dem Rest der Bemühungen, die in die Entwicklung von Code fließen.