Здравствуйте, Pzz, Вы писали:

C>>Допустим, есть некоторый протокол, для которого определены структуры данных. Раньше можно было описать их на Си, затем подключать полученный заголовочный файл, куда нужно — хочешь, генерируй обёртки для Java, хочешь — для Python, а можешь сразу в С++ использовать. Сейчас же Си и С++ довольно далеко разошлись. Настолько, что простой union из нескольких полей и равного по размеру массива (типичное представление вектора в Си) может привести к UB.
Pzz>Это всегда было UB. Но на практике работало. Потому, что все понимали, что есть 100500 системного кода, который на это рассчитывает.

Ещё можно явно барьеры компилятору ставить через atomic_signal_fence().
Записал в одно поле union, поставил барьер, прочитал другое поле.
Оптимизация чуть пострадает, но для задачи разбора таких структур, кажется, без разницы, затраты на сеть будут больше.

Можно для одного файла (или даже функции, GCC умеет) сократить оптимизации.

Pzz>Можно сделать полноценый маршалинг. Т.е., считаем внешнее представление последовательностью байтов, руками собираем, руками разбираем.

И это тоже.

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

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

Здравствуйте, Pzz, Вы писали:

C>>Допустим, есть некоторый протокол, для которого определены структуры данных. Раньше можно было описать их на Си, затем подключать полученный заголовочный файл, куда нужно — хочешь, генерируй обёртки для Java, хочешь — для Python, а можешь сразу в С++ использовать. Сейчас же Си и С++ довольно далеко разошлись. Настолько, что простой union из нескольких полей и равного по размеру массива (типичное представление вектора в Си) может привести к UB.
Pzz>Это всегда было UB. Но на практике работало. Потому, что все понимали, что есть 100500 системного кода, который на это рассчитывает.

Ещё можно явно барьеры компилятору ставить через atomic_signal_fence().
Записал в одно поле union, поставил барьер, прочитал другое поле.
Оптимизация чуть пострадает, но для задачи разбора таких структур, кажется, без разницы, затраты на сеть будут больше.
Или WRITE_ONCE + READ_ONCE образца Linux (которые внутри превращаются в volatile-доступы).

Можно для одного файла (или даже функции, GCC умеет) сократить оптимизации.

В общем, методы ещё есть. Пока не все зарезали

Pzz>Можно сделать полноценый маршалинг. Т.е., считаем внешнее представление последовательностью байтов, руками собираем, руками разбираем.

И это тоже.

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

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