Salat13 Nov 26 2020 at 14:03

А вы умеете готовить nested_flatbuffers?

15 min

4.5K

Programming*C++*C*

Tutorial

+12

Comments 3

vglavnyy Nov 26 2020 at 16:22

Мне кажется вам не нужны union в такой простой схеме:

union CommonMessage
{
    Request,
    Response
}
table MessageHolder
{
    data: CommonMessage;
}

Достаточно хранить их вместе:

table MessageHolder
{
    request: Request;
    response: Response;
}

Тип можно будет определить проверкой на пустоту поля response или request.
Пустая таблица места не занимает. Оверхэд если и будет, то +1 байт по сравнению с union (можно проверить с помощью flatc).
В этом случае Response можно сделать структурой, а не таблицей.
Но так можно делать только если уверены в том, что схема не изменится (не надо будет добавлять новых таблиц в union).

Если же используете union, то зачем вам потом нужен Header?
Вы можете явно спросить тип union в поле data: data_type().

Salat13 Nov 26 2020 at 16:29

1) В такой простой можно и без юниона
Но в вашем случае функции MessageHolder_create надо будет все равно предоставлять все аргументы, даже для неиспользуемых таблиц. У меня на проекте, например, таких таблиц 15 штук, и тут уже общая вместо юниона вообще не пойдет, увы. Поэтому я сразу рассматривал более общий подход

2) В плане «структура, а не таблица» — да, согласен. Я знаю про эту разницу, что для фиксированных простых типов так и надо, но решил не усложнять примеры разнообразием типов, чтоб не запутать читателей.
Например, в реальном приложении у нас сплошь используются string, массивы и простые вложенные структуры, поэтому там чисто tables — наверное уже по привычке и здесь так же сделал

3) Насчет header — согласен, здесь я мог наворотить. Надо проверить

vglavnyy Nov 26 2020 at 16:54

В плане «структура, а не таблица» — да, согласен.

Это предложение было только для моего примера без union.
Структуры нельзя помещать в union. В объединении могут быть только ссылочные nullable типы. Например, можно добавить строку без таблицы-обертки.

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

Я не предлагал отказаться от nested_flatbuffer в серверном сообщении, тут он полезен.
Копирующий Create можно добавить, просто он не был нужен. Pull-request приветствуется, как и с любым open-source.

Show the best of all time