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

Кастовать область памяти в указатель на какой-нибудь тип нельзя, если не хочешь в будущем поиметь множество сюрпризов, особенно во время портирования на другие архитектуры. Можно сделать memcpy память -> структура. Вариант с ручным разбором более гибкий в том плане, что не любые данные "ровно" ложатся в структуру, для них требуется предварительная обработка. Например массивы заранее неизвестной длины, взаимосвязи между разными структурами и т.д.

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

А вот с 


мне как-то не совсем понятно, как в этом случае быть с big endian? 

newbee, спасибо за ответ
Не совсем понял на счет проблем при касте в указатель на структуру, если подразумевается, как пишет 
rumit7, порядок байт и выравнивание, то как memcpy решает проблему? (присоединяюсь к вопросу 
rumit7)

Господа, если у вас намечаются проблемы с порядком байт, достаточно просто перевернуть необходимые слова внутри структуры (т.к. между словами байты не перетасуются, только в рамках слова). Если ваша система будет обмениваться информацией между собой одновременно на разных системах, конечно нужен договор о порядке байт: при отправке данных они кодируются в сетевой порядок, во время приема декодируются в хостовый.

Я писала совсем о другом: в общем случае нельзя кастовать некий буфер данных в свои переменные. Пример проблемы. Чтобы в будущем не нажить проблем? лучше сразу приучить себя всегда использовать memcpy для копирования сырых данных в свои пользовательские.

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

А если предположить, что формат задан по спецификации и построен по следующим принципам:

•  первый байт является тэгом сообщения, т.е. определяет его тип;
•  следующие 2 байта определяют общую длину данного сообщения;
•  далее идет содержимое сообщения. Здесь могут находится вложенные сообщения, идентифицирующиеся также по тегу или просто содержимое какой-то структуры.

Тэги всех сообщений заданы. Формат их задан. Единственно что: многие сообщения являются опциональными, т.е. их присутствие не гарантируется. 

Так вот, в таком случае: как мог бы выглядеть парсер? Интересует правильный дизайн парсера с точки зрения читабельности полученного кода и эффективности реализации. 

Я ниже приведу свои мысли, а если кто-то подскажет что-то - буду очень признателен!


Имеется буфер содержащий целое количество сообщений (т.е. дочитывать еще данные нет необходимости).

 

Дальше буфер нужно парсить. Использовать внутри "parse_buffer" целую кучу switch, if-ов в стиле процедурного программирования не выход, особенно если спецификация на формат достаточно обширная. Здесь бы воспользоваться преимуществами с++, но как правильно это сделать?! Есть ли идеи?

Думаю в любом случае, получив тэг (число) надо будет выбрать обработчик, т.е. сопоставить значение с исполнителем, тут либо switch либо через табличку (switch, как правило, компилятор реализует табличкой).

Да, конечно не без этого, но хотелось бы найти решение. Пока крутится в голове что-то в этом роде: