Forger

можно перегрузить даже "глобальный" new/delete, это заложено в базе языка, но это не всегда и порой совсем не удобно в моей ситуации пришлось "лезть глубже" с перегрузками под несколько другой причине, но вряд ли кому-то это будет интересно ) причем у вас о чисто виртуальный (= 0), что требует обязательной реализации этого метода в наследнике, то очень удобно, согласитесь )) довольно часто использую такой механим, очень полезный функционал, особенно для создания базовых интерфейсных классов (что типа паттерн "фасад"), через которые идет общение с наследниками второй полезный плюс такого класса - невозможно создать его экземпляр без наследования,

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

Вы не правы, эти самые new/delete как раз и вызывают библиотечные malloc/free и др. Если не верите, сделайте свои пустые заглушки на эти библиотечные функции и убедитесь лично под отладчиком. Я поэтому и переделал их, что при вызове new/delete используются по-умолчанию слишком простые и рисковые библиотечные malloc/free. Благо библитека позволяет чуть ли не все переписать под себя как угодно. В этом плане плюсы никуда не ушли от си видимо мы говорим о несколько разных вещах ) я пришел к совершенно простому для меня объяснению - плюсы это по сути НАДСТРОЙКА на голым си, а никак не замена целиком. А вот с C# ситуация с дин памятью как раз в корне была изменена и уже такие мои "фокусы" вряд ли прокатят (

По-моему аллокатор дин. памяти не относится к языку как таковому, что в плюсах, что в си используется вызов библиотечных malloc/free и реже других. Меня никогда не устраивал штатный аллокатор, поэтому тупо перегрузил штатные библиотечные функции дин памяти своими и уже там вызываю аллокатор. За основу взят TLSF как есть, но с немного другими настройками, особенно на контроллерах с мелким озу. Причем аллокатора пришлось делать два - один первичный, используется на "раскручивание" системы, совсем крохотный в 64 байта, а уже когда запустится все внутри подключается полноценный аллокатор. Связано с некоторыми библиотечными функциями, обойти по другому пока не получилось.

но это уже началось )))

ну вот и тут коснулись традиционной темы "религии", местные служители "Культа Экономии Драгоценного Бита" скоро прибудут )))

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

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

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

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

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

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

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

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

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