Как сократить перевод из типа в массив?

Воспользоваться msgpack?

memcpy?

http://pastebin.com/4qeYCPka

Жесть.

htons/htonl, не трогай байты. Убери le/be, есть только хост и нетворк ордеры, первый не сериализуется. Почему vars не union.

Почему все эти велоподелия не умеют в хотя бы опциональные бэк-референсы на уже сериализованные значения, кто-нибудь в курсе? Даже в эппловском п-листе сам же икскод юзает костыли с путями/уидами чтобы ссылаться на ноды в одном файле.

есть только хост и нетворк ордеры, первый не сериализуется.

У меня Christie сервер, у которого прямо внутри пакета меняется порядок байт для записываемых интов LE / BE / LE. Т.е. вот так для трех единиц: 00 00 00 01 01 00 00 00 00 00 00 01. Что-что мне убрать?

Почему vars не union

Потому что используется в другом месте, там могут много значений лежать. Есть и юнионный вариант, он в другом месте юзается.

Меня больше волнует, насколько у меня гарантировано повыравнивается юнион и можно ли было написать его проще.

Как можно его сократить/упростить так, чтобы не было UB (типа сдвига знаковых)

Не писать бесполезное дерьмо.

ненужно сервер, у которого прямо внутри пакета меняется порядок байт для записываемых интов

Тогда просто конвертни сначала в network order (hton*), потом из него уже забирай байты по смещениям. Маловероятно, но формально ты можешь быть запущен на архитектуре с нативкой не 1234 или 4321, а например 2143.

Меня больше волнует, насколько у меня гарантировано повыравнивается юнион и можно ли было написать его проще.

Сунь паддинг отдельным полем, выкинь его из частных структур (а, так он там уже есть, зачем тогда структур наворотил?). Члены юниона имеют один адрес, выравниваются по правилам, как если бы просто там лежали в одиночку. Я может что-то упускаю, но чет не вижу проблем с union { int64_t; uint64_t; ...; char[8]; }. Ну и по коду непонятно, зачем там вообще эта подушка.

просто конвертни сначала в network order (hton*), потом из него уже забирай байты по смещениям

Нет hto* для 64 бит.

Маловероятно, но формально ты можешь быть запущен на архитектуре с нативкой не 1234 или 4321, а например 2143.

Буду запущен на старой слаке на ~1500 нодах. Архитектура меняться не будет, максимум что поменяется - на трех нодах х64 вместо х32

Члены юниона имеют один адрес

Вооооо. Вот ради этой фразы я и пытался что-то прояснить. Я не смог найти в стандарте гарантирование того что разные по длине типы буду выравнены на один адрес.

Ну и по коду непонятно, зачем там вообще эта подушка.

Чисто из-за см. выше.

Это «бесполезное дерьмо» обеспечивает тебе работу кинотеатров.

А, ясно.

Нет hto* для 64 бит.

htonl(x & UINT32_MAX), htonl(x >> 32). Но если архитектура фикс, то я бы и париться не стал (наверное, у меня на это дело иногда случается ОКР).

не смог найти в стандарте

Я тоже не lawyer, вот цитата цитаты из википедии.

Structure and union specifiers have the same form. [ . . . ] The size of a union is sufficient to contain the largest of its members. The value of at most one of the members can be stored in a union object at any time. A pointer to a union object, suitably converted, points to each of its members (or if a member is a bit-field, then to the unit in which it resides), and vice versa.

— ANSI/ISO 9899:1990 (the ANSI C standard) Section 6.5.2.1

ps. вместо UINT32_MAX читать ~(uint32_t)0 или типа того.

http://pastebin.com/4qeYCPka

Here be dragons.

Про htons/htonl уже выше сказали.

Ввах! спасибо, теперь хотя бы долбаные структуры уйдут.

В принципе у меня еще есть мысль добавить в xmacro, который задает собственно список типов еще и поле BE/LE, а весь текущий огород свернуть в десяток строк с if (BE) flip + memcpy. Вопрос только стоит со сложными типами тпа STRING16 и RBYTES (возможно еще добавить придется), но там можно сделать ветку отдельную.

Спасибо вам за помощь.

Это «бесполезное дерьмо» обеспечивает тебе работу кинотеатров.

Нет. Кинатеатры работают сами, вернее как - не будет этого дерьма - будет другое, да и мне они не интересны.

А замес ашота мне обеспечивает рабочу кинотеатра не меньше. Впрочем как всегда - бесполезное агро.

Дерьмо не та задача которую ты решаешь, а те методы, которыми ты её решаешь.

Даже убожество с hton* намного более вменяемо.

Я не смог найти в стандарте гарантирование того что разные по длине типы буду выравнены на один адрес.

Выравнивание большего типа всегда выравнивает все меньшие.

Хотя наличие packed там, где он ни в одном случае не нужен и в целом бессмысленность сего действа - показательна. Но зато агроамстер.

Раскрой же свои секреты, о, Мастер!

Секреты чего? Как не делать бесполезное дерьмо? В данном случае? У меня нет исходных данных. В общем - хотя-бы понимать что делаешь и зачем.

По поводу того - почему я это написал - дело в портянке. Она не имеет смысла от слова никакого. Этого достаточно.

Дерьмо не та задача которую ты решаешь, а те методы, которыми ты её решаешь.
Секреты чего?

Секреты расово верных методов сериализовать инты (ну и похоже плавающую точку), согласно твоему мнению. Протокол известен, ссылка выше.

Секреты расово верных методов сериализовать инты (ну и похоже плавающую точку), согласно твоему мнению.

Не эта задача, а изначальная - это метод решения. Именно он и не имеет смысла, как и попытки в той портянке.

Сериализация не имеет смыла и не нужна. Нигде, никогда.

По работе приходится гонять пакеты со словарями, массивами, строками, числами по сети и диску. Платформы [будут] разные абсолютно, какая альтернатива сериализации?

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

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

Откуда взялись строки - мне не ведомо и нахрен их надо сериализавать? Тут проще взять готовое - один хрен уже ничего вменяемого не получится.

Платформы [будут] разные абсолютно, какая альтернатива сериализации?

Что значит будут? У кого - где? Это очень редкий случай, но и это ничего не меняет. Отправляй тогда текст - форматы чисел везде могут быть разные.

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

Нахрена нужно отправлять 100500 типов чиселок - мне не ведомо. Это типа экономия трафика? А текст сжимается? Нахрена вообще посылать какие-то отдельные чиселки - так же не ясно.

Какая-то неведомая херня попахивающая анскиллом.

Нахрена вообще посылать какие-то отдельные чиселки - так же не ясно.

Держи, «анскильная лалка»: https://www.barco.com/tde/(1800891131681511)/TDE3800/00/Barco_ReferenceGuide_...
http://www.alcorn.com/library/manuals/man_dvmhd.pdf
http://www.tolleredsbiograf.se/page/teknik/Dolby_CP750_Manual.pdf
На Christie уж извини, дается только после покупки сервака за 5+ млн.

Потом расскажешь, как сказать устройству «включи пятый канал» без сериализации

Держи, «анскильная лалка»

Что я там должен увидеть?

На Christie уж извини, дается только после покупки сервака за 5+ млн.

Дядя запретил пастить мануальчик, либо у тебя его нет, но ты кукарекаешь? Зачем ты мне это сообщаешь?

Потом расскажешь, как сказать устройству «включи пятый канал» без сериализации

О боже - никого не волнует то дерьмо, что у тебя есть. Это никак не отменяет её не нужно, а то, что протоколы и вся херня сделаны от анскила для анскила - ничего не меняет. Зачем ты это постишь?

Each command is packaged in this structure
0xFE   Start byte         (1 byte)
ADDR   Device address     (1 byte)
PREFIX Prefix             (0..n bytes)
CMD    Command            (1..n bytes)
DATA   Data               (0..n bytes)
CHK    Checksum           (1 byte)
0xFF   Stop byte          (1 byte)

Эти протоколы для колхозников - ты мне покажешь тут «сериализацию»? Или перданёшь в лужу?

На вопрос так и не ответил. По первой ссылке никакого упоминания на тему нет, кроме мультибайта в be, но выше я сказал как с этим быть. И того - зачем посылать «отдельные» чиселки мне так и не ответили.

Для этого анскилла есть жабка, маздайка и любой колхозник. Агро - уровень пятикласник.

О боже, о боже - я только сейчас это увидел " TCP/IP network." и Checksum в одном мануале. Мне было бы стыдно даже портянку такую пастить, не то что пугать ею.

ты мне покажешь тут «сериализацию»?

(1..n bytes)

Для этого анскилла есть жабка, маздайка и любой колхозник

Она жрет много памяти и процессора, плюс даже близко не реалтайм. Никакой дебил кроме царя не будет писать либо опроса оборудования на жабе.

" TCP/IP network." и Checksum в одном мануале

А если бы ты прочел мануал ты бы увидел, что устройство так же может в RS-232, никто не будет разрабатывать два разных протокола для двух типов соединения, о, мой лохматый друг.

(1..n bytes)

Это делается бвапом, а бсвап не является «сериализацией». Т.е. так ничего и не показал.

Да и не показал что за данные надо посылать. Т.к. это колхозный протокол - скорее всего там кроме строк ничего и не осилилось.

Она жрет много памяти и процессора,

Твоё дерьмо так же. В каждой строчке тонна оверхеда и лоускилла.

плюс даже близко не реалтайм

Как и твоё дерьмо. Или твоя вера делает вдруг из дерьма реалтайм? Прям ка у жабистов.

Никакой дебил кроме царя не будет писать либо опроса оборудования на жабе.

Ну да - опрос в 150кбпс на убогом протоколе на убогой железяке.

А если бы ты прочел мануал ты бы увидел, что устройство так же может в RS-232,

Зачем мне смотерть? Я вижу дерьмо.

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

Будут, если там будет что-то сложнее хелворда. Ну ладно. Как это оправдывает ущербанство этого недопротокола?

Он дерьмо? Дерьмо. А то, что там у тебя ещё умеет - это никак ничего не меняет.

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