Какой смысл использовать std :: ios_base :: binary?
У меня была проблема с чтением файла Linux в Window. Вот обсуждение вопроса: Использование fstream :: seekg под windows для файла, созданного под Unix.
Проблема была решена путем открытия текст файл с std::ios_base::binary указано.
Но какой смысл в этом режиме? Если указан, вы все еще можете работать с вашим файлом как текстовым файлом (запись с mystream << "Hello World" << std::endl и читать с std::getline).
Под Windows единственное отличие, которое я мог заметить, заключается в том, что mystream << "Hello World" << std::endl использует:
0x0D 0x0Aв качестве разделителя строк, еслиstd::ios_base::binaryне был указан (EOL и возврат каретки)0x0Aв качестве разделителя строк, еслиstd::ios_base::binaryбыл указан (только EOL)
Блокнот не показывает строки при открытии файлов, созданных с помощью std::ios_base::binary, Лучшие редакторы, такие как vi или Wordpad, показывают их.
Разве это единственная разница между файлами, созданными с и без std::ios_base::binary? Документация говорит Consider stream as binary rather than text.Что это значит в конце?
Безопасно ли всегда устанавливать std::ios_base::binary если я не забочусь об открытии файла в блокноте и хочу иметь fstream::seekg всегда работать?
Решение
Различия между двоичным и текстовым режимами являются реализацией
определены, но касаются только самого низкого уровня: они не меняют
смысл таких вещей, как << а также >> (которые вставляют и извлекают текстовые
данные). Кроме того, формально, выводя все, кроме нескольких непечатных
символы (как '\n') неопределенное поведение, если файл находится в тексте
Режим.
Для наиболее распространенных ОС: в Unix нет различий; оба
идентичны. Под виндой '\n' внутренне будет сопоставлен с двумя
последовательность символов CR, LF (0x0D, 0x0A) внешне и 0x1A будет
интерпретируется как конец файла при чтении. В более экзотических (и в основном
вымершие) ОС, однако, они могут быть представлены совершенно разными
типы файлов на уровне ОС, и может быть невозможно прочитать файл в
текстовый режим, если он был написан в двоичном режиме, и наоборот. Или ты
мог видеть что-то другое: лишние пробелы в конце строки или
нет '\n' в двоичном режиме.
Что касается всегда настройки std::ios_base::binary: моя политика для
переносимые файлы, чтобы решить, как именно я хочу их отформатировать, установите
двоичный файл, и выведите то, что я хочу. Который часто CR, LF, а не просто
LF, так как это сетевой стандарт. С другой стороны, самый
У программ Windows нет проблем только с LF, но я сталкивался
более чем несколько Unix-программ, которые имеют проблемы с CR, LF; который
выступает за систематическое использование только LF (что тоже проще). дела
все это означает, что я получаю одинаковые результаты независимо от того,
Я работаю под Unix или под Windows.
Другие решения
Значение текстового потока против двоичного потока зависит от платформы и несколько непредсказуемо.
Но что касается популярных платформ, то все просто: в Linux и MacOS X разницы нет. В Windows единственная разница заключается в том, что внутренний \n переводится на \r\n во внешнем потоке.