Почему (i | o) fstream принимает параметр const char * для имени файла? - PullRequest
16 голосов
/ 12 мая 2011

Почему конструктор и open метод классов fstream std: :( ​​i | o) принимают имя файла в качестве параметра в виде const char* вместо std::string? Создается впечатление, что создатели STL захотят использовать написанное вместо того, чтобы использовать тип, который они написали, для замены.

Ответы [ 5 ]

13 голосов
/ 12 мая 2011

Часть библиотеки string была разработана после потоков, и никто не думал вносить очевидные изменения.

Это просто из политической и временной реальности, которую они никогда не удосужились до того, как отправить C ++98, и никто не удосужился поднять его снова, потому что вы всегда можете решить это с помощью .c_str().

C ++ 0x исправляет это (см. 27.9.1.6).

Добро пожаловать в C ++.

6 голосов
/ 12 мая 2011

Насколько я знаю, это в основном по историческим причинам.ifstream и ofstream существовали задолго до std::string.У них даже тогда не было std::.

4 голосов
/ 12 мая 2011

Класс std::string реализует концепцию "строки изменяемого размера во время выполнения".Это когда этот класс должен использоваться - когда вам нужна строка, размер которой известен только во время выполнения, а также изменяемого размера во время выполнения.В ситуациях, когда вам не нужны эти функции, использование std::string является излишним.По-видимому, авторы библиотеки не думали, что им нужна строка изменяемого размера во время выполнения для представления имени файла, поэтому они выбрали минималистичное решение: они использовали C-строку, где C-строка была достаточной.На самом деле это очень хороший принцип для проектирования библиотечных интерфейсов: никогда не требуйте то, что вам действительно не нужно.

Это правда, что в наши дни мы часто видим людей, которые поощряют программистов C ++ использовать std::string всякий раз, когда онинужна строка, любая строка.Они часто утверждают, что классические C-строки должны быть зарезервированы для C-кода.В общем случае это фиктивная философия.Бесплатное использование сравнительно тяжелых объектов, таких как std::string, более подходит в таких языках, как Java, но обычно неприемлемо в C ++.

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

3 голосов
/ 12 мая 2011

Моя ставка в том, что иерархия / библиотека iostream (включая (i|o)fstream) была изобретена / разработана отдельно от std::string, и они впервые встретились, только когда собрались в библиотеке std.
ВВо время изобретения iostream, возможно, было много различных реализаций string, которые поддерживали максимальную переносимость, они решили сделать ставку на тип данных, который всегда доступен, и это простая строка char const* в стиле c.

2 голосов
/ 12 мая 2011

Просто просматривая мой заголовок G ++ <fstream>, я заметил, что все ссылки на std::basic_string или любые его typedefs находятся в разделах, ограниченных #ifdef __GXX_EXPERIMENTAL_CXX0X__.

Это говорит о том, что библиотека iostreams была разработана, чтобы быть независимой от библиотеки строк, поэтому, если вы не использовали std::string, вам не пришлось бы платить за нее (это исторически было очень важно принцип дизайна в C ++). Это также объясняет, почему getline(std::istream&, std::string&) является свободной функцией, определенной в <string>, а не функцией-членом, такой как istream::getline(char*, streamsize).

Это также наводит на мысль, что в стандартизации C ++ 0x это воспринималось как недостаток дизайна и я решил, что неудобство, связанное с независимостью библиотеки iostreams от библиотеки строк, просто не стоит.

(Меня не беспокоит поиск рабочего проекта спецификации C ++ 0x или систематическая проверка всех связанных с iostreams заголовков, чтобы подтвердить что-либо из этого.)

...