Может ли объединение проводить сбор или упаковку?

Question

В руководстве beej по работе с сетями есть раздел сортировки или упаковки данных для сериализации, где он описывает различные функции для упаковки и распаковки данных (int, float, double ..etc).

Проще использовать union (аналогичные значения могут быть определены для float и double), как определено ниже, и передавать integer.pack как упакованную версию integer.i, а не функции pack и unpack.

union _integer{
  char pack[4];
  int i;
}integer;

1. Может кто-нибудь пролить свет на то, почему союз - плохой выбор?

2. Есть ли лучший способ упаковки данных?

Answer 1

Разные компьютеры могут размещать данные по-разному. Классическая проблема - это endianess (в вашем примере, имеет ли pack [0] MSB или LSB). Использование такого объединения связывает данные с определенным представлением на компьютере, который их сгенерировал.

Если вы хотите увидеть другие способы маршалинга данных, посмотрите Boost serialization и Google protobuf .

Answer 2

Союзный трюк не гарантированно работает, хотя обычно это работает. Это вполне допустимо (в соответствии со стандартом) для вас, чтобы установить данные типа char, а затем читать 0, когда вы пытаетесь прочитать int, или наоборот. Union был разработан для микрооптимизации памяти, а не замены для приведения.

В этот момент обычно вы либо заключаете конверсию в удобный объект, либо используете reinterpret_cast. Немного громоздкий или некрасивый ... но ни одна из этих вещей не обязательно плохая, когда вы упаковываете данные.

Answer 3

Почему бы просто не сделать reinterpret_cast в char* или memcpy в буфере char? Они в основном одно и то же и менее запутанные.

Ваша идея сработает, поэтому, если хотите, продолжайте, но я считаю, что чистый код - это счастливый код. Чем легче понять мою работу, тем менее вероятно, что кто-то (например, мое будущее я) сломает ее.

Также обратите внимание, что в объединение можно поместить только типы POD (простые старые данные), что накладывает некоторые ограничения на подход объединения, которых нет в более интуитивном.