Дизайн класса std :: ifstream

Question

Те из нас, кто видел красоту STL, стараются использовать его как можно чаще, а также побуждают других использовать его везде, где мы их видим, используя необработанные указатели и массивы, Скотт Мейерс написал целую книгу по 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, поэтому не комментируйте мой заголовок. Это выглядит коротко, поэтому я использовал его.

Фактический шаблон класса:

template<class _Elem,class _Traits> class basic_ifstream;

Answer 1

Поскольку IOStream был разработан задолго до того, как часть STL была интегрирована в стандартную библиотеку. И класс строки был сделан после этого. В процессе стандартизации было довольно поздно, и изменение IOStream не считалось сохранением.

Кстати, как часть незначительных, но удобных изменений в C ++ 0X, произошла очистка от подобных вещей.

Answer 2

Моя копия стандарта не согласна с вами.В нем говорится, что оба являются перегрузками:

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

Однако эта копия стандарта является черновиком следующей версии стандарта, C ++ 0x.

Причина этого заключается в том, чточто библиотека iostreams предшествует std::basic_string, и потому, что разработчики библиотеки не хотели, чтобы кто-то имел #include <string> и весь его другой связанный багаж, если они не хотели его использовать.

Answer 3

Как правило, получить строку C из std::string обычно не дороже, чем создать std::string из строки C, поэтому, учитывая, что вы, вероятно, захотите использовать std::ifstream с именами файлов из использование const char* в интерфейсе не является значительным расходом.

Это серьезная ошибка с дизайном?

Что вы не можете сделать с текущим интерфейсом? Какое конкретное и значительное преимущество принесло бы const std::string& в интерфейсе?

Реальное преимущество перегрузки std::string, на мой взгляд, состоит в том, чтобы помочь новичкам, упростив их в правильном понимании при первой попытке использовать std :: string и потоки вместе. Для опытных разработчиков C ++ тривиальная стоимость написания .c_str() при необходимости, вероятно, будет незначительной по сравнению с остальными усилиями, которые уходят на разработку кода.