Мне нравится vscode. Но в основном из-за его легкости, расширяемости и универсальности (один редактор для всего), удобством настроек в текстовом файле, а не монструозном ui
К тому же для vscode легко пишутся собственные расширения, что сильно подкупает.
Передавать прошивки (бинарники) можно разными способами, хоть на листочке хексы печатать.
Для таких организаций, где нет систем контроля версий проще в ide, или в редакторе кода настроить форматирование по хоткеям. Или в принципе не заниматься этим. Так как скорее программист единственный и о командной работе над одной кодовой базой тут речи и быть не может. Либо это будет сущим адом.
Умеет:
https://clang.llvm.org/docs/ClangFormatStyleOptions.html#allowallparametersofdeclarationonnextline
В чем необходимость компоновки аргументов функций именно таким образом?
Для этого можно использовать clang-format, он может генерировать отчет о несоответствии шаблону. И им же можно форматировать.
Принимайте мои соболезнования
Кодстайл и статический анализ это две разные задачи и не должны смешиваться
Зависит от стандарта языка, который вы используете. Для си >= с2х это не нужно
К слову, typedef не переопределяет тип и не создает тип, а лишь определяет псевдоним.
Да делайте, что хотите, изобретайте кучу странных скриптов и практик. Я вам показал путь без извращений, дальше сами.
Проблема с отображением затененных кусков кода это чисто проблема эклипса, в нем и нужно её решать.
Мне нравится vscode. Но в основном из-за его легкости, расширяемости и универсальности (один редактор для всего), удобством настроек в текстовом файле, а не монструозном ui
К тому же для vscode легко пишутся собственные расширения, что сильно подкупает.
Не призываю использовать, просто делюсь мнением.
Открываете настройки проекта и настраиваете провайдеры для препроцессора.
Отметил только тот который реализует функционал вашей статьи. Остальное тоже посмотрите, думаю пригодится.
Все это делается одной простой настройкой и все ваши самописные мэйкфайлы и константы из них подтягиваются и нормально отображаются а редакторе.
Под капотом эклипс делает тихую пустую сборку и уже на основе этого отображает верно.
Не нужно изобретать, нужно уметь пользоваться инструментом который выбрал.
Но, на мой взгляд, эклипс сейчас наихудший выбор для писанины кода.
Наврядли там чистый js и HTML, скорее куча плохопонимаемого кода, который если написать руками будет сильно меньше.
Передавать прошивки (бинарники) можно разными способами, хоть на листочке хексы печатать.
Для таких организаций, где нет систем контроля версий проще в ide, или в редакторе кода настроить форматирование по хоткеям. Или в принципе не заниматься этим. Так как скорее программист единственный и о командной работе над одной кодовой базой тут речи и быть не может. Либо это будет сущим адом.
Ему место в прекомит хуках, как писали выше или в чем-то подобном.
Какой толк от него в системе сборки?
Вы по одному автору статьи не судите о всей индустрии. Стиль и задачи описанные автором, это чисто его проблемы.
Согласен, что высосано из пальца и всё решается куда проще. Но такой уж стиль автора
*.lst весьма полезен при отладке просто в консоли и без исходников, а вот бин и хекс легко вытаскиваются из элфа
На основной вопрос из заголовка "как...?" статья никак не отвечает
Ну что же, переводить тоже нужно с толком
Ужас какой, проще использовать скрипты для расчётов на каком-нибудь питончике.
Потом если надо можно и на сервер сборки прицепить и генерить коэффициенты в компайлтайме, если надо.
Если очень хочется никто не запрещает вернуть структуру или принять отдельным параметром указатель и заполнить всё необходимое.
К любым рекомендациям необходимо подходить скептически и с оглядкой на прикладную задачу, а не фанатично плодить сущности.