Будет ли Endianness проблемой для этого типа операции двоичного ввода-вывода? - PullRequest
2 голосов
/ 08 марта 2012

Для экономии места я решил закодировать мои файлы сохранения, используя двоичные файлы.Каждый байт представляет идентификатор для типа плитки.Может ли это вызвать проблемы с другими вычислениями Endian?

Кроме того, из любопытства, это ЦП или операционная система, которая устанавливает тип Endian?

Дополнительная информация: Я использую C ++ ипостроение игровой платформы xЯ не хочу использовать дополнительный API, такой как Boost.

Ответы [ 2 ]

5 голосов
/ 08 марта 2012

Да, это вызовет проблемы - , если загруженный файл из BE загружается на LE или наоборот.Вот почему некоторые Unicode-кодировки, такие как UTF-16 и UTF-32, имеют так называемый маркер порядка следования байтов.

Если ваш код обычно компилируется в BE, вам все равно придется убедиться, что код LEпоменяет порядок байтов перед использованием данных.

ЦП устанавливает Endianess, и некоторые микросхемы (например, некоторые ЦПУ MIPS) позволяют это переключать при загрузке системы.

3 голосов
/ 08 марта 2012

Мы могли бы использовать немного больше информации. Кроссплатформенность это одно, а какие платформы? Если вы имеете в виду кроссплатформенность, такую ​​как x86 Mac, x86 Linux и x86 Windows, то вам не нужно об этом беспокоиться (хотя структура упаковки все еще может быть проблемой, если вы попытаетесь просто записать структуры на диск и скомпилировать с различными компиляторами на разные платформы). Даже если у вас есть пара различных комбинаций ОС / ЦП, вы можете составить список всего, что вы хотите поддерживать, и, если они имеют одинаковую последовательность, не беспокойтесь об этом.

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

Кроме того, поскольку вы упоминаете только байты, если байтовый массив настолько сложен, насколько ваши данные собираются получить, вам на самом деле не нужно беспокоиться о порядке байтов. Это проблема только для многобайтовых типов данных. Поэтому, если вы просто сохраняете байтовые массивы, а остальные ваши бухгалтерские данные также помещаются в байтах, вам не о чем беспокоиться, но как только вы сохраните short, int или float, у вас возникнут потенциальные проблемы с порядком байтов.

Мое личное мнение таково, что когда вы сериализуете, принимайте во внимание порядок байтов, но у меня чрезвычайно многоплатформенный опыт (то есть, поставка одного и того же продукта на 5 игровых системах). Это довольно просто, макросы подкачки уже есть, и когда вы неизбежно решите перейти к другому порядку байтов, вам не придется переписывать материал. Если данные более сложные или структурированные, возможно, стоит рассмотреть такую ​​библиотеку, как буфер протокола или BSON.

И ЦП, и операционная система могут быть ответственны за бесконечность. Исторически он был встроен в центральный процессор, и, хотя x86 по-прежнему зашит как «младший», большинство современных производных RISC могут работать в любом режиме, что делает его выбором для разработчиков аппаратного обеспечения и ОС.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...