Какой смысл использовать std::ios base:: binary?

у меня была проблема с чтением файлов Linux под окном. Вот вопрос обсуждения:использование fstream:: seekg под windows в файле, созданном под Unix.

вопрос был workarounded путем открытия текст С 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 всегда работает?

6
c++ eol iostream stl

2 ответов

различия между двоичным и текстовым режимами являются реализацией определены, но касаются только самого низкого уровня: они не изменяют значение таких вещей, как << и >> (которые вставляют и извлекают текст данные.) Кроме того, формально, вывод всех, кроме нескольких непечатаемых символы (например,'\n') - неопределенное поведение, если файл находится в тексте режим.

для наиболее распространенных ОС: под Unix нет никакого различия; оба идентичный. Под Окнами,'\n' внутренне будет отображаться на два последовательность символов CR, LF (0x0D, 0x0A) внешне и 0x1A будет интерпретируется как конец файла при чтении. В более экзотических (и в основном вымершие) Осс, однако, они могут быть представлены совершенно разными типы файлов на уровне ОС, и может быть невозможно прочитать файл в текстовый режим, если он был написан в двоичном режиме, и наоборот. Или вы может видеть что-то другое: дополнительное белое пространство в конце линии или нет!--2--> в двоичном режим.

в отношении всегда настройки std::ios_base::binary: моя политика portable files-это решить, как именно я хочу их отформатировать, установить binary, и выведите то, что я хочу. Который часто CR, LF, а не просто LF, так как это стандарт сети. С другой стороны,--11-->большинство Программы Windows не имеют проблем только с LF, но я столкнулся более нескольких программ Unix, которые имеют проблемы с CR, LF; которые аргументирует за систематическое использование только LF (что проще, слишком.) Делающий все это означает, что я получаю те же результаты, независимо от того, Я работаю под Unix или под Windows.

7

значение текстового потока против двоичного потока зависит от платформы и несколько непредсказуемо.

но что касается популярных платформ, это легко: на Linux и MacOS X нет никакой разницы. В Windows единственная разница заключается в том, что internal \n переведен на \r\n во внешнем потоке.

0