S>Но вообще если бы такая задача возникла — использовать сериализатор — то зачем его писать с нуля, когда есть готовые, годами отлаженные?
А ты зачем пишешь? Есть же готовые, годами отлаженные?
S>>>2. Скорость — чтобы быль чем меньше лишних преобразований (особенно тяжелых — без фанатизма) и копирований памяти туда-сюда. M>>Приведённый пример вполне отвечает этому критерию
S>Ну в вашем же коде для сериализации — если нужно по итогу получить массив байт uint8_t* для FFI — нужно будет создать буффер (вектор байт) — и по сути скопировать в него все данные — расширяя _buff.resize(_buff.size() + size);
Не факт, что пакет надо сразу отправлять. Но не вижу проблем переделать под OutputIterator, который будет класть данные прямо в сокет. Но, вообще, ты не думал, что вызов системного вызова send для каждого байта по отдельности будет гораздо дороже, чем передать в send заранее подготовленный пакет целиком?
А на STM32, где я точно знаю, что никаких накладных расходов на вызов функции передачи нет — я именно там в UART и клал, через OutputIterator.
S>Т.е. по сути делается дурная работа — перекладывание байт из одного хранилища m_place в другое. Зафига?
Дурная работа — это когда ты делаешь необоснованные выводы и начинаешь заниматься оптимизацией, а потом реальность, жестокая штука, показывает, что узкое место совсем не там, и тебе приходится всё переделывать (а придётся, потому что ты сильно заложился на свои предположения)
S>Я этого шага избежал с помощью перемещения — забрал просто уже существующие байты пакета, т.к. они уже ему, готовому к умному погребению, более не понадобятся.
Это решается в несколько строчек кода через OutputIterator, который может класть хоть в сокет, хоть в массив
