Просто ваше решение опирается на сомнительные имена.
Честно говоря, я вообще не понимаю, что это значит
Уделяете много внимания незначительной проблеме и упускаете более серьезные и трудно отлаживаемые.
Приведите, пожалуйста, пример таких проблем, которые я упускаю (как это вообще можно понять из данной статьи?).
Я повторю, как и для комментатора выше, если я посвятил время теме регистров, это не значит что я только и я только этому и посвящаю свое время. И если я тчо-то не описал, это не значит что этого нет.
Вопрос в том, какие проблемы значительные тогда? Вы привели кусок кода (без контекста), по которому не особо и понятно, что это и для чего. При этом, выглядит еще и непонятнее того, что я предлагаю.
Там проблема просто понять работу этих битов и их зависимости. Поэтому лучший путь никак не маскировать и не шаблонизировать, а использовать прямые однозначные записи по явным адресам с подробными коментариями.
Я и сам уважаю принцнцип Keep It Simple Stupid. Однако, по такой логике, вообще ничего нельзя использовать, если не уверен до конца как это работает внутри, ни одной библиотеки, вообще.
Если я правильно понял, что своим примером вы обозначили, что заменяете 'чтение-модификация-запись' на 'запись'. Никто не запрещает так делать и с моим решением.
Отвечая на вопросы:
А можно ли так делать в конкретной ситуации? Что тут произойдет в случае прерывания?
А как на это отвечает CMSIS? Не всегда возможно заменить 'чтение-модификация-запись' на запись 'запись' Думаю, что тут программист может за это отвечать.
Как С++ ответит на такой вопрос?
Также как и C
А как в отладчике будет выглядеть проход по шаблонам?
Я особой разницы не вижу.
Можно ли будет просто найти соответствие между ассемблерным кодом и кодом шаблона?
А какой фрагмент статьи заставил вас думать, что нужно размазывать работу с регистрами ровным слоем по всем исходникам? Или городить безумные слои абстракции?
Я вообще не 'показал подход' - я лишь показал, как добавить безопастность и не потерять ничего.
На самом деле, с точки зрения концепции, при высоко абстрагированном подходе, С и С++ не сильно и отличаются. Взять хотя-бы тот-же 'объектно-ориентированный' C, с указателями на функции и композицией. На нем ведь написано очень много чего, тот же Linux например.
Слои абстракции возникают (по крайней мере, должны возникать) не просто так, а для того, чтобы каждую часть проекта можно было безболезненно заменить в случае смены чипа/интерфейса/пина/формата данных и т.п.
Однако, правда и в том, что C++ программы склонны к переусложнению, просто из-за объема языка и его возможностей (довольно часто попадался такой код). Если именно это главная проблема, то я бы посмотрел на Rust.
И не надо, pls, придумывать им свои термины "динамический/статический полиморфизм" и пр
Это широко распространненная терминология. Просто как пример: Джосаттис Николаи М., Грегор Дуглас, Вандевурд Дэвид. Шаблоны C++. Справочник разработчика. Второе издание. Часть 3, Глава 22: Статический и Динамический полиморфизм. (стр. 581) И это еще до C++20 и концептов концептов.
может все же при разработке программы?
Подозреваю, что именно при выполнении, так как не происхоит косвенных вызовов по vtable.
Шаблоны в С++ это "ой. макросами как то не очень. Давайте придумаем новый инструмент".
Это не так даже в первом приближении.
ИМХО, статический полиморфизм хорошая альтернатива динамическому в очень многих ситуациях.
Тоже пришел к подобной связке, только вместо CMake->Make, один раз написал файл и он сам ищет все .c .cpp .h .hpp в желаемых папках. И расширение для отладки Native Debug, оно более общее.
Мне нравятся подобные решения, так как имея минимальный набор инструментов можно собирать проекты для любых чипов, любой конфигурации на бесплатных обновляемых инструментах (Для меня это критично, так как использую некоторые фичи С++20, для чистого С обновляемость компилятора не так важна).
Я полностью поддерживаю вашу точку зрения. Как видите, статья была написана 2 года назад и сейчас я считаю такой подход ошибочным. Честно говоря, я думаю, что это был дерьмовый код со всех сторон.
Спасибо за разъяснение!
Я одно время вообще кучу не использовал в проектах под embedded, сейчас сталкиваюсь с большими проектами, где куча используется.
Вообще, я для себя рассудил так. У меня прошивка без использования кучи под домашние проекты занимает не более 10-20 кБайт. На всех используемых мною камнях памяти от 128 до 512 кБайт. Почему не пожертвовать ей, если это улучшит переносимость и гибкость кода.
Это лишь моё мнение касательно моих проектов, оно может измениться. Повторюсь, ещё совсем недавно я был противником использование кучи в МК для несложных проектов.
С вами мне спорить трудно, знаю по вашим публикациям что вы очень давно в IAR работаете.
Я лишь описал то, что выдал мне отладчик при беглом просмотре, возможно я не так понял и вы правы.
Это очень сильное заявление.
Мой двух-годичный опыт жизни в Германии говорит мне, что это вообще НЕ так.
Вообще, весь комментарий очень сомнительный, у меня, как и у многих моих иммигрировавших знакомых противоположный опыт.
Отвечу то же, что отвечал уже несколько раз под этой статьей.
Я НЕ призываю писать все на регистрах. Этот слой нужен для написания драйверов, и только в случае если вам нужно написать драйвера.
Расскажите мне пожалуйста, как статический анализотор поможет диагностировать ошибки, упомянутые в статье.
Честно говоря, я вообще не понимаю, что это значит
Приведите, пожалуйста, пример таких проблем, которые я упускаю (как это вообще можно понять из данной статьи?).
Я повторю, как и для комментатора выше, если я посвятил время теме регистров, это не значит что я только и я только этому и посвящаю свое время. И если я тчо-то не описал, это не значит что этого нет.
Вопрос в том, какие проблемы значительные тогда? Вы привели кусок кода (без контекста), по которому не особо и понятно, что это и для чего. При этом, выглядит еще и непонятнее того, что я предлагаю.
Я и сам уважаю принцнцип Keep It Simple Stupid. Однако, по такой логике, вообще ничего нельзя использовать, если не уверен до конца как это работает внутри, ни одной библиотеки, вообще.
Если я правильно понял, что своим примером вы обозначили, что заменяете 'чтение-модификация-запись' на 'запись'. Никто не запрещает так делать и с моим решением.
Отвечая на вопросы:
А как на это отвечает CMSIS? Не всегда возможно заменить 'чтение-модификация-запись' на запись 'запись' Думаю, что тут программист может за это отвечать.
Также как и C
Я особой разницы не вижу.
Можно, активно это делал во время разработки.
А какой фрагмент статьи заставил вас думать, что нужно размазывать работу с регистрами ровным слоем по всем исходникам? Или городить безумные слои абстракции?
Я вообще не 'показал подход' - я лишь показал, как добавить безопастность и не потерять ничего.
Я согласен с вами. Не понял только один момент:
Но ведь это же и есть одна из главных фишек моего решения
Или имеется ввиду то, что под капотом?
То, что вы перечислили, это же не проблемы C++
На самом деле, с точки зрения концепции, при высоко абстрагированном подходе, С и С++ не сильно и отличаются. Взять хотя-бы тот-же 'объектно-ориентированный' C, с указателями на функции и композицией. На нем ведь написано очень много чего, тот же Linux например.
Слои абстракции возникают (по крайней мере, должны возникать) не просто так, а для того, чтобы каждую часть проекта можно было безболезненно заменить в случае смены чипа/интерфейса/пина/формата данных и т.п.
Однако, правда и в том, что C++ программы склонны к переусложнению, просто из-за объема языка и его возможностей (довольно часто попадался такой код). Если именно это главная проблема, то я бы посмотрел на Rust.
Не могли бы вы пояснить, что вы имеете ввиду?
Аргументы будут? Как тогда сделать правильно?
Это широко распространненная терминология. Просто как пример:
Джосаттис Николаи М., Грегор Дуглас, Вандевурд Дэвид. Шаблоны C++. Справочник разработчика. Второе издание. Часть 3, Глава 22: Статический и Динамический полиморфизм. (стр. 581)
И это еще до C++20 и концептов концептов.
Подозреваю, что именно при выполнении, так как не происхоит косвенных вызовов по vtable.
Это не так даже в первом приближении.
ИМХО, статический полиморфизм хорошая альтернатива динамическому в очень многих ситуациях.
Если речь о Blaue Karte, по которой иммигрирует подавляющее большинство IT сектора, то не зависит, выше правильно написали
Тоже пришел к подобной связке, только вместо CMake->Make, один раз написал файл и он сам ищет все .c .cpp .h .hpp в желаемых папках.
И расширение для отладки Native Debug, оно более общее.
Мне нравятся подобные решения, так как имея минимальный набор инструментов можно собирать проекты для любых чипов, любой конфигурации на бесплатных обновляемых инструментах (Для меня это критично, так как использую некоторые фичи С++20, для чистого С обновляемость компилятора не так важна).
Так как?
Добрый день, cпасибо за комментарий!
Я полностью поддерживаю вашу точку зрения. Как видите, статья была написана 2 года назад и сейчас я считаю такой подход ошибочным. Честно говоря, я думаю, что это был дерьмовый код со всех сторон.
Теперь я перешел на что-то вроде этого: https://github.com/isobchuk/cpp_register (просто пример).
Однако я не согласен с замедлением в 10 раз с виртуальными функциями. Мой опыт разбора дизамблера и некоторые статьи говорят о другом.
И все же сейчас, я предпочитаю статический полиморфизм динамическому при написании универсальных кода.
Я одно время вообще кучу не использовал в проектах под embedded, сейчас сталкиваюсь с большими проектами, где куча используется.
Вообще, я для себя рассудил так. У меня прошивка без использования кучи под домашние проекты занимает не более 10-20 кБайт. На всех используемых мною камнях памяти от 128 до 512 кБайт. Почему не пожертвовать ей, если это улучшит переносимость и гибкость кода.
Это лишь моё мнение касательно моих проектов, оно может измениться. Повторюсь, ещё совсем недавно я был противником использование кучи в МК для несложных проектов.
Я лишь описал то, что выдал мне отладчик при беглом просмотре, возможно я не так понял и вы правы.