Forger

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

Во первых - длиНа, во-вторых, как понять что пакет пришел? байт стаффинг с уникальных завершающим символом или межкадровый таймаут? если нет ничего из этого, а данные идут потоком, то как вы предлагаете понять где они закончились не зная заранее их ожидаемый объем? в изначальном посте не было ни слова про некие "бинарные" протоколы

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

так я ж о чем и пишу - ДО начала данных, а не как у вас - в конце у меня было всегда примерно в таком порядке: заголовок, код команды, длина поля данных, КС (всего кадра или только данных), сами данные и финальный заголовок (если нужен), как например это сделано в CAN можно КС размещать и после данных, но для этого ОБЯЗАТЕЛЬНО нужно в кадре указывать сколько их (поле длины), иначе как понять где искать эту самую КС? можно КС разместить в самом начале, сразу после заголовка, если он конечно одинаковый для всех кадров, может быть у вас окончание кадра определяется по межсимвольному таймауту, и между кадрами время тоже ограничено минимальным значением, то тогда да, можно отказаться от поля длины данных в особо тяжелых случаях можно использовать составной кадр - управляющая часть со своей КС, это кадр строго фиксированного размера и кадр с данными, там своя КС в этом случае в кадре данных действительно достаточно разместить в их начале заголовок, потом данные и потом КС, но даже в таком случае в управляющем кадре все равно есть поле длины кадра с данными был у меня такой проект и в нем были команды с кадрами данных и без

с "гибким"? чтобы менялось в рантайме? так конечно нет, это ж структура )) но можно хранить в структуре указатель на массив с данными Или остается использовать кучу, а это известно что за собой несет. Если идти с кучей дальше, то есть в конце концов std::vector можно немного изменить протокол введя ограничение по длине поля данных и добавить поле длины данных (один или два байта) тогда можно работать со структурой фиксированного максимально размера, но зная сколько там реальных данных это будет куда проще, чем разгребать последствия активного использования векторов (кучи) еще придется переместить поле контрольной суммы ДО начала данных, никто не заставляет хранить ее в самом конце так делал, работало прекрасно, да и щас работает )

старинные средневековые традиции, скрепы ))

Чтобы отделить тип от объекта. Это принципиально разные вещи, т.к. одно никогда не сможет стать другим. Например, если тип называется с большой буквы, то точно также может называться его объект: TimeMs timeMs = 0; Если смешивать, то такие записи будут невозможны.

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

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

так зачем это нужно - выделять их из общей массы? просто давно не пользовался глобальными обеъектами и как-то подзабыл )

А зачем это нужно? К слову, у меня вообще нет глобальных объектов, кроме локальных с припиской static. Но и когда были, тоже не делал разницы.

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

а для меня это оказалось весьма пагубной практикой, и в основном от этого как раза довольно жирного (для меня) минуса: Для себя понял одном самое важное в куче правил - чем их меньше и чем они проще, тем легче потом работать со своим же кодом через какое-то время. У меня есть самое главное и простое правило: все типы строго с Большой буквы, а их объекты - с маленькой. Без исключений. Никаких префиксов в типах и именах. Т.е. все как в жизни ) Впрочем, опять уходим во вкусовщину ))

ага, начиная с C++20 ))

Если уж наделять структуры такими заумными возможностями, то, что мешает их надели уже неким "функционалом", некими действиями? 😉 Ведь структура - это по сути класс, а значит может не только хранить данные, но и выполнять разные действия с их передачей, приемом, контролем целостности. Для этого им нужно дать методы передачи своих команд. Например, "дать" во владение некий порт обмена или передать ей метод для работы с тем или иным портом или даже списком портов Таким образом рождается некая иерархия команд: есть базовые, а есть те, которые построены на их основе и дают больше возможностей. Такие команды должны уметь работать с итераторами (списками), чтобы не "перебирать" их вручную. Другой вопрос - насколько это нужно в том или ином проекте. Чем плоха самая обычная структура с безымянным union и т.п? Зачем так усложнять? Ведь должна быть цель, оправдывающая такие усложнения )