Извините, ничего не найдено.

impersonalis · 30.06.2012, 01:38

Определимся с терминологией. Под бинарным файлом здесь я понимаю такой способ организации (накладывающей особенности на операции чтения/записи) хранения информации в файле, при которой данные представляют собой, по сути дамп памяти. Иными словами, переменная

int x=123456;

при записи в бинарный файл, занимает ровно 4 байта (т.е. sizeof(int) ) и при открытии целевого файла блокнотом не читается в "человеческом" восприятии.
При записи той же переменной в текстовый (не бинарный) файл, переменная займёт 6 байт (при ASCII-кодировании), каждый из которых будет кодировать одну цифру.
Для Blitz basic: бинарный режим - функции типа ReadInt/WriteInt, текстовый - WriteLine.

Плюсы бинарного режима: возможность сэкономить на памяти и стандартизировать требования к её размерам; возможность сохранять произвольные разнородные данные простой запись куска памяти.
Минусы: возможность потратить память (например, если сохраняемые числа в диапазоне [0..999] для int) и полностью утратить возможность к стандартизации (разные архитектуры и платформы); невозможность сохранять данные простой записью куска памяти (разный порядок байт внутри переменной в зависимости от архитектуры, выравнивания и полный хаос со структурами, беготня, спотыкания и ещё большая непереносимость с директивами #pragma pack; адресация членов объекта через указатели, приводящая к необходимости написания отдельных методов его сохранения).

Получается, что бинарные файлы - это хак. Его переносимость весьма условна.
В то же время, используя текстовый формат, мы по сути, перекладываем обязанности по загрузке\выгрузке (трансляции из файла\в файл ) на функции типа atoi\itoa, работающие на более высоком уровне абстракции: медленнее, но зато без оглядки на "аппаратные" особенности.

Речь даже не только о файлах, но о любой сериализации (ту же структурку по сети кинуть - как кодировать?).

Опрос открытый

Спасибо всем кто осилил излияния и дочитал до конца.
Просьба сильно не пинать, если где-то заблуждаюсь

Mr_F_ · 30.06.2012, 01:53

оффлайн данные для игры необходимо хранить в бинарном виде, максимально близком к его представлению в памяти. иное не нужно.
данные, нужные для редактирования в процессе разработке лучше иметь в более универсальном читабельном виде - по крайней мере опыт использования редактируемых данных в бинарном виде у меня негативный.
по сети слать хз, я работу с сетью писал для проекта, в котором протокол был 100% стандартизирован, а скорость критична, так что были бинарные структуры.

30.06.2012, 01:54

в практическом понимании : бинарный файл это любой файл для редактирования содержимого которого нужно использовать hex (или специфический) редактор

в теоретическом понимании : любой файл = бинарный файл, те это синонимы, но если внутри бинарных файлов данные представлены в текстовой кодировке (ASCII, UTF-8, UTF-16) и тд, то данные называют текстовыми данными, но файл по прежнему бинарный (ведь в utf есть нехитрый такой хак чтобы определить порядок битов в байте, собсно отсюда текст это данные, но никак не файл)

SBJoker · 30.06.2012, 01:55

Вообще то при чтении можно задавать порядок байт в слове, тем самым обойти апаратные отличия в кодировании чисел.

Увлечение переносимостью и читабельностью файлов привело к созданию монстров типа XML, на парсинг которых уходит огромное количество процессорного времени.

Обоим типа записи быть, это можно заметить по тому что многие программы имеют как бинарный так и текстовый тип файла. Например DWG и DXF.

А вообще тип записи выбирается исходя из конкретных задач. Например конфигурационные файлы, для которых скорее всего небудет создан редактор, лучше делать текстовыми для правки их любым текстовым процессором. А например файлы сохранения игры, лучше реализуются бинарным способом.

impersonalis · 30.06.2012, 01:58

Сообщение от jimon

в практическом понимании : бинарный файл это любой файл для редактирования содержимого которого нужно использовать hex (или специфический) редактор

в теоретическом понимании : любой файл = бинарный файл, те это синонимы, но если внутри бинарных файлов данные представлены в текстовой кодировке (ASCII, UTF-8, UTF-16) и тд, то данные называют текстовыми данными, но файл по прежнему бинарный (ведь в utf есть нехитрый такой хак чтобы определить порядок битов в байте, собсно отсюда текст это данные, но никак не файл)

вот специально для таких хитрых я и написал длинное вступление. Спасибо, конечно, за философское уточнение, ещё можно рассказать, что все данные это 0 и 1, а потом спустится ещё ниже - к непрерывным аналоговым сигналам... по теме же - ни слова

Randomize · 30.06.2012, 02:01

Скажем так. Всё зависит от задачи.

Если данные летят по сети и их реально много, то однозначно бинарные.

Для хранения на диске примерно так:
Если данные достаточно однотипны (например тайловая карта) то тут быстрее и удобнее писать её бинарно.
Ежели данные разнообразные - неравномерные, то проще текстом.
Упакованные данные конечно в бинарном виде.
Данные в которых только текст как ни странно в текстовом виде

Хотя текст и есть бинарные данные, но я твою мысль понял

Кстати, а если в текстовом виде байты чрез запятую написать это текстовый формат или нет?

Сугубо личное мнение.

impersonalis · 30.06.2012, 02:02

Сообщение от SBJoker

Вообще то при чтении можно задавать порядок байт в слове, тем самым обойти апаратные отличия в кодировании чисел.

Пожалуйста, подробнее (цпп).
Опять-таки проблема со структурами остаётся. Можно конечно, сначала всё разбирать до базовых типов, а сохранять уже отдельно их...

Сообщение от Randomize

Если данные летят по сети и их реально много то однозначно бинарные.

согласен полностью, но с сожалением.

Randomize · 30.06.2012, 02:08

Сообщение от impersonalis

согласен полностью, но с сожалением.

Почему? Текст пожалуй нужен только для наглядности.
Текст это тоже самое только человекочитаемо.

impersonalis · 30.06.2012, 02:14

Сообщение от Randomize

Почему? Текст пожалуй нужен только для наглядности.
Текст это тоже самое только человекочитаемо.

Текст - лишён ряда недостатков, которых не лишены другие типы данных (для jimon: да, я намеренно упрощаю формулировку, чтобы её можно было прочитать в течение дня; да - противопоставление некорректно). Т.е. на одной машине - big-endian, на другой - little-endian, но текстовое представление этого числа - одинаковое (цифры слева-направо по убыванию степеней). Т.е. текст - своеобразный интерфейс.
Организация структур - усмотрение компилятора, директивы управления этим процессом делают код менее портабельным и модульным.

Mr_F_ · 30.06.2012, 02:26

Текст - лишён ряда недостатков, которых не лишены другие типы данных (для jimon: да, я намеренно упрощаю формулировку, чтобы её можно было прочитать в течение дня; да - противопоставление некорректно). Т.е. на одной машине - big-endian, на другой - little-endian, но текстовое представление этого числа - одинаковое (цифры слева-направо по убыванию степеней). Т.е. текст - своеобразный интерфейс.

что-то мне подсказывает, что конвертнуть big endian в little endian быстрее, чем парсить человекочитаемый текст.

impersonalis · 30.06.2012, 02:38

Сообщение от Mr_F_

что-то мне подсказывает, что конвертнуть big endian в little endian быстрее, чем парсить человекочитаемый текст.

безусловно (я об этом писал выше). Осталось только продумать соответствующую отметку в файле. И не забыть её при загрузке учесть. А ещё и код написать, который сам будет определять специфику архитектуры, на которой он выполняется (думаю, это реально, но как, лично я - не знаю).

HolyDel · 30.06.2012, 02:39

зависит от задачи

почти всегда хватает бинарных. конфиги там всякие - удел текстовых.

impersonalis · 30.06.2012, 02:40

Сообщение от HolyDel

зависит от задачи

почти всегда хватает бинарных. конфиги там всякие - удел текстовых.

и как обойти проблемы совместимости?

ABTOMAT · 30.06.2012, 02:42

Бывает важно экономить.
Бывает важна человекочитаемость/скорость разработки.
бывает подо что-то уже есть готовый велосипед.
Так что "только то" либо "только это" ответить нельзя.

Mr_F_ · 30.06.2012, 02:47

а где вообще конкретно такие проблемы с совместимостью встречались?