Но так делать не надо. В данном случае норм, но если будет ещё одно "вычисляемое" условие, то пока вы "выполняете" первое, второе уже может поменятся. Поэтому правильно, вначале оба значения для условия "вычислить" а потом условия "соблюсти".
Насчёт более безопасен, не знаю. По моему опыту, что IAR 8.40.2, что IAR 8.40.3FS генерят абсолютно одинаковый код и имеют абсолютно одинаковые баги.
Но без сертифицированного компилятора, вы не сможете получить сертификат безопасности для устройства для которого вы пишите софт. А таких я знаю пока только два: IAR и Green Hill
Ок, тогда условие задачи немного другое, мы не знаем какого типа и сколько параметров у функции do_something, и должны „прибиндить" параметры, передаваемые во врапер в произвольном порядке к параметрам этой функции.
Про span ещё не читал, C++20 пока в embedded нет. У меня вопрос.
Разумеется, где-то будет операция обращения к элементу по-индексу (operator[]), логику которого следует изменить, чтоб при обращении к несуществующему индексу было исключение, возврат ошибки, static_assert наконец
Кидать исключения в ембед не принято, слишком накладно, проверять выход за границу каждый раз при обращении тоже, а вот про static_assert не понял. Если, я индекс передаю как параметр оператора, то значит предполагается, что этот индекс можно передаваться не только в compile-time, но и runtime и значит static_assert там не проканает. Я же хочу использовать свой буфер в любом времени исполнении.
Идея, описанная здесь заключается в том, что мы можем с имитировать рантайм поведение объекта в компайлтам, и проверить это на этапе компиляции. Ну скажем так, возможно это похоже на контракты, которые проверяются в компайлтам тайме.
Я может не до конца понял условие задачи, но если вы проверяете статик ассертом, что параметров 3, то почему в шаблон нельзя просто передать три разных типа?
Насколь я понимаю, осталось два вида компиляторов, Clang и GCC. И всё остальные компиляторы это просто надстройки, возможно со своей реализацией стандартной библитнки и всяких там доп фич и возможностями оптимизации т. Д.
IAR начиная с 8 версии основан на Clang, со всеми вытекающими. Основное его преимущество, наличие Functional Safety версии
Согласен, внешние генерилки хорошая вещь, главное, чтобы генерила все правильно без всяких закладок и в нужном формате. Вот в С++ 20 завезут consteval, возможно чисто теоретически можно будет лазить к ресурсам в проекте (например в bmp файл) на этапе компиляции и самому оттуда вытаскивать все.
Да, все верно, правильно сразу задать x и y знаковые. Беззнаковые нужны только при установке точки в буфере, но только надо быть уверенным, что они беззнаковые - это как раз IAR компилятор и на этапе компиляции constexpr объекта отлавливает, потому что такое скомпилировать не может.
Да согласен. Уже не помню зачем, так сделано было.
P. S. Вспомнил, это же буфер иконки, она должна быть доступна для отрисовки. Общий метод рисования иконок подразумевает, что в метод передастся иконка, у которой есть свой буфер. Некоторые иконки трудно нарисовать математическими функциями и они всё таки генерятся из внешних тулов в массив. Но функция рисования иконок одна и ей нужен этот константный массив, в который уже ничего рисовать не надо.
Но с рисованием круга согласен, надо убрать внутрь.
Да, рисование круга так и сделано в DrawLibrary::DrawCircle. Там входной параметр как раз буфер, но всё должно быть в самом constexpr обьекте. Т. Е нельзя создать буфер вне такого объекта и передать функцию объекта. Он должен быть частью этого объекта.
Спасибо за статью, идея хорошая, не могли бы пояснить, зачем вообще иметь древовидную структуру хранения параметров? Почему например нельзя просто сделать параметры индивидуальные и обращаться к ним по имени?
С2_12.backup(37.2F);
SuperComplexParameter.backup({1,10.f, tSring6"Hello"});
B1_1.backup(tString6{"Hello"});
LcdContarst.backup(50); //Пишем в EERPOM Один параметр c контрольной суммой
Если надо по индексу к ним обращаться то можно запихать их в список, ну типа такого.
using tParams1 = NvVarList1 <С2_12, B1_1, LcdConrast>;
tParams1::get(0).set(37.2F); //Запись в ОЗУ
tParams1::get(2).set(50);
tParams1::backup() - //пишем в EEPROM сразу все параметры с контрольной суммой для списка
Можно сделать несколько таких списков и делать ссылку друг на друга
using tParams = NvVarList <С2_12, B1_1, LcdConrast, Params1>;
Params1::get(0).set(10);
tParams::get(0).set(37.2F); //Запись в ОЗУ
tParams::get(2).set(50);
tParams::backup() - //пишем в EEPROM сразу все вместе со списком Params1
Но это правда на С++, зато там нет никаких указателей.
Если что описание параметра будет выглядеть как то так:
Начальное значение тут нужно для того, чтобы задать что-то в случае, если при считывании параметра будет ошибка контрольной суммы.
Ссылка на драйвер - можно подсовывать любой, который будет работать хоть с со страничной, хоть с обычной, хоть с ОЗУ и памятью программ. Он и будет обеспечивать особенности работы разных ПЗУ.
Эта фишка называется integral promotion. И без оптимизации компилятор все делает, по стандарту
A.6.1 Integral Promotion
A character, a short integer, or an integer bit-field, all either signed or not, or an object of enumeration type, may be used in an expression wherever an integer may be used. If an int can represent all the values of the original type, then the value is converted to int; otherwise the value is converted to unsigned int. This process is called integral promotion.
Эта фишка называется integral promotion. И без оптимизации компилятор все делает, по стандарту
A.6.1 Integral Promotion
A character, a short integer, or an integer bit-field, all either signed or not, or an object of enumeration type, may be used in an expression wherever an integer may be used. If an int can represent all the values of the original type, then the value is converted to int; otherwise the value is converted to unsigned int. This process is called integral promotion.
Но так делать не надо. В данном случае норм, но если будет ещё одно "вычисляемое" условие, то пока вы "выполняете" первое, второе уже может поменятся. Поэтому правильно, вначале оба значения для условия "вычислить" а потом условия "соблюсти".
Насчёт более безопасен, не знаю. По моему опыту, что IAR 8.40.2, что IAR 8.40.3FS генерят абсолютно одинаковый код и имеют абсолютно одинаковые баги.
Но без сертифицированного компилятора, вы не сможете получить сертификат безопасности для устройства для которого вы пишите софт. А таких я знаю пока только два: IAR и Green Hill
https://www.ghs.com/products/compiler.html
Он аж на SIL4 сертифицирован.
То надо вставить static_assert на проверку, чтобы такого не было.
Ок, тогда условие задачи немного другое, мы не знаем какого типа и сколько параметров у функции do_something, и должны „прибиндить" параметры, передаваемые во врапер в произвольном порядке к параметрам этой функции.
Про span ещё не читал, C++20 пока в embedded нет. У меня вопрос.
Кидать исключения в ембед не принято, слишком накладно, проверять выход за границу каждый раз при обращении тоже, а вот про static_assert не понял. Если, я индекс передаю как параметр оператора, то значит предполагается, что этот индекс можно передаваться не только в compile-time, но и runtime и значит static_assert там не проканает. Я же хочу использовать свой буфер в любом времени исполнении.
Идея, описанная здесь заключается в том, что мы можем с имитировать рантайм поведение объекта в компайлтам, и проверить это на этапе компиляции. Ну скажем так, возможно это похоже на контракты, которые проверяются в компайлтам тайме.
Я может не до конца понял условие задачи, но если вы проверяете статик ассертом, что параметров 3, то почему в шаблон нельзя просто передать три разных типа?
И проверяйте внутри типы... И весь этот гемор с поиском типа по паку уйдёт.
Да там действительно будет 1 пиксель пустых полосок, я написал, что это самое быстрое :), чтобы показать, что ошибка переполнения ушла.
Насколь я понимаю, осталось два вида компиляторов, Clang и GCC. И всё остальные компиляторы это просто надстройки, возможно со своей реализацией стандартной библитнки и всяких там доп фич и возможностями оптимизации т. Д.
IAR начиная с 8 версии основан на Clang, со всеми вытекающими. Основное его преимущество, наличие Functional Safety версии
https://www.iar.com/safety
Что даёт возможность его использования для разработки Functional Safety устройств.
Согласен, внешние генерилки хорошая вещь, главное, чтобы генерила все правильно без всяких закладок и в нужном формате. Вот в С++ 20 завезут consteval, возможно чисто теоретически можно будет лазить к ресурсам в проекте (например в bmp файл) на этапе компиляции и самому оттуда вытаскивать все.
Да, все верно, правильно сразу задать x и y знаковые. Беззнаковые нужны только при установке точки в буфере, но только надо быть уверенным, что они беззнаковые - это как раз IAR компилятор и на этапе компиляции constexpr объекта отлавливает, потому что такое скомпилировать не может.
Да согласен. Уже не помню зачем, так сделано было.
P. S. Вспомнил, это же буфер иконки, она должна быть доступна для отрисовки. Общий метод рисования иконок подразумевает, что в метод передастся иконка, у которой есть свой буфер. Некоторые иконки трудно нарисовать математическими функциями и они всё таки генерятся из внешних тулов в массив. Но функция рисования иконок одна и ей нужен этот константный массив, в который уже ничего рисовать не надо.
Но с рисованием круга согласен, надо убрать внутрь.
Да, рисование круга так и сделано в DrawLibrary::DrawCircle. Там входной параметр как раз буфер, но всё должно быть в самом constexpr обьекте. Т. Е нельзя создать буфер вне такого объекта и передать функцию объекта. Он должен быть частью этого объекта.
Спасибо за статью, идея хорошая, не могли бы пояснить, зачем вообще иметь древовидную структуру хранения параметров? Почему например нельзя просто сделать параметры индивидуальные и обращаться к ним по имени?
Если надо по индексу к ним обращаться то можно запихать их в список, ну типа такого.
Можно сделать несколько таких списков и делать ссылку друг на друга
Но это правда на С++, зато там нет никаких указателей.
Если что описание параметра будет выглядеть как то так:
Начальное значение тут нужно для того, чтобы задать что-то в случае, если при считывании параметра будет ошибка контрольной суммы.
Ссылка на драйвер - можно подсовывать любой, который будет работать хоть с со страничной, хоть с обычной, хоть с ОЗУ и памятью программ. Он и будет обеспечивать особенности работы разных ПЗУ.
Да все верно компилятор делает. В соответствии со стандартом.
У компилятора все правильно.
Эта фишка называется integral promotion. И без оптимизации компилятор все делает, по стандарту
У компилятора все правильно.
Эта фишка называется integral promotion. И без оптимизации компилятор все делает, по стандарту
Извиняюсь, машина тоже лает на собакую Видимо заменил телефон, а я не посмотрел.
Мне показалось, что машина тоже дать на собаку.
Спасибо!
А я думаю, что это не реклама, поэтому думаю, ссылку на сайт можно было и дать. Интересно же и еще если не секрет и на исходники.