Little endian to Big endian conversion в C++, необходим ли для бинарной сериализации?

Question

[Trrrrr]

Собственно, есть кроссплатформенный код. Задача стоит реализовать бинарное сохранение данных, данные потом будут читаться не только с с++.
Я так понял, в Windows Little Endian. Но есть платформы, где у нас Big Endian.

Что я хочу - написать такой код, который гарантировано будет сохранять в сетевом порядке байты (Big Endian).
Что я пока придумал:

Некий макрос, например, отсюда: stackoverflow.com/questions/2100331/c-macro-defini...

тогда функция будет иметь такой вид:

void saveInt(int a)
{
#ifdef BIG_ENDIAN
save(a);
#else // little endian
int b = htonl(a);
save(b);
#endif
}

Может, можно как-то веселее такое реализовать, а то такую функцию для каждого типа данных писать.
Ну и верно ли я понял, что htons всегда переворачивает байты? Если нет, то получается, такой код не нужен, просто всегда вызывать ее, а у нее внутри что-то вроде кода, который я написал.

Answer 1

[xandox]

В posix системах (в винде проверить не могу, но скорее всего то же где-то должно быть) есть семейство функций для работы с big endian и little endian.

По поводу твоего вопроса я бы сделал примерно так

unsigned short store(unsigned short s) { return htobe16(s); }
unsigned int store(unsigned int s) { return htobe32(s); }
unsinged long store(unsigned long s) { if (sizeof(unsinged long) == 8) return htobe64(s); else return htobe32(s);}

unsigned short restore(unsinged short s) { return be16toh(s); }
// и т.д.

ну тут как видишь тебе придется еще решить вопрос с unsinged long. он, в зависимости, от битности системы имеет разный размер.

PS. На самом деле big endian встречается сейчас только на встраиваемых системах и на игровых консолях и вообще говоря зависит не от ОС, а от процессора. На x86 и amd64 всегда little endian. По сему подумай - а надо ли тебе это.

Comments

[Trrrrr]

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

[xandox]

Я бы на твоем месте еще подумал на тему - а нужна ли тебе бинарная сериализация. Имхо от нее больше проблем чем пользы. В крайнем случае - посмотри в сторону google protobuf или apache thrift.

[Trrrrr]

@xandox да нужна, небинарная и так есть :) гоняем xml и json в заархивированном виде. Но при чтении двух метровго xml чуствуются тормаза.

[xandox]

Ну тогда смотри в сторону protobufa - он решит все твои проблемы.

[Trrrrr]

протобаф - это кодо генерация, в моем случае как из пушки по воробьям. Мне на самом деле это не особо важно. У меня там просто массивы флоатов и других данных. Вопрос в том, как их сохранять, что бы везде одинаково сохранялось. Но я прочитал что и на андроиде le используется, выходит на всех моих платформах le и не надо мудрить.

[wander]

@Trrrrr Раньше маки работали на PowerPC, который мог быть big-endian. Если старые маки не нужны, то тогда действительно не надо мудрить.

Answer 2

[Миша Кринкин]

Функция htonl конвертирует host порядок байт в сетевой порядок байт (т. е. в Big Endian), независимо от того, какой на самом деле на host используется порядок, т. е. вся препроцессорная логика не нужна (она уже есть в htonl).

Порядок байт нужно зафиксировать, но он не обязан быть Big Endian, можно с успехом использовать Little Endian, и если все платформы работают с последним, то париться не придется вообще, если же есть Big Endian клиент, то парится придется только на нем (если конечно не хочется написать один код для всех клиентов, в этом случае лучше использовать htons или аналогичную функцию для Little Endian).

Если говорить о бинарной сериализации, то фиксировать нужно не только порядок байт, но и размер, т. е. использовать типы вроде uint32_t. Функции hton* и так их используют, но у тебя в коде используется int, что не очень хорошо.