Почему файловые потоки C ++ 03 не принимают параметры строкового конструктора? - PullRequest
3 голосов
/ 28 февраля 2012

Почему следующий код компилируется в C++11, а не в 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 в качестве параметра конструктора? Было ли это решение основано на чем-то или оно произошло случайно?

Ответы [ 3 ]

9 голосов
/ 28 февраля 2012

Сбой кода при компиляции со строго соответствующим компилятором C ++ 03, потому что конструктор, который принимает std::string, был добавлен только в C ++ 11.

Что касается вопроса, «был ли он основан на чем-то умном», поскольку интерфейс был добавлен , то можно сделать вывод, что для его пропуска не было технической причины.

Это дополнительное удобство, так как, если у вас есть std::string, вы всегда можете вызвать .c_str(), чтобы получить строку C, подходящую для использования со старым интерфейсом. (Как сказано в документации на C ++ 11, конструкторы, которые принимают std::string, имеют точно тот же эффект, что и вызов соответствующего конструктора, который принимает const char* с результатом вызова .c_str() в строка.)

5 голосов
/ 28 февраля 2012

Насколько я помню, это обсуждалось на clc ++. M несколько лет назад, и Эндрю Кениг (я думаю, это был Эндрю, во всяком случае) сказал, что на самом деле это поднималось во время некоторых встреч, , но идеяпринятие string было быстро связано с идеей принятия wstring, и оттуда перешло к обсуждению поддержки интернационализированных наборов символов в именах файлов, и ... вскоре после этого вся идея была отброшена, потому чтоон открыл большую банку с червями, с которыми никто не был готов иметь дело.

2 голосов
/ 28 февраля 2012

Они просто забыли о добавлении конструктора string в C ++ 03. Теперь это исправлено. На этот раз другие вещи были забыты, как make_unique. Всегда есть что-то большее, что можно было бы сделать. C ++ 03 также забыл указать аргументы по умолчанию для шаблонов функций, которые теперь включены.

Редактировать: Как говорит @Charles, это может быть не буквальное «забвение», а, скорее, что-то, что должно быть там, но просто не было указано по той или иной причине. Дальнейшие примеры дают std::next / std::prev, которые являются большим облегчением, и std::to_string и std::stoi/d/ul/ull, которые снова имеют смысл, но никто не удосужился указать их до этого времени. Для их предыдущего отсутствия не обязательно есть глубокая причина.

...