Нет никаких проблем под виндой, а wsl, как вы сказали выручает, если нужно проверить собираемость под линуксом или использовать чисто линуксовый софт. Одно огорчение было под виндой в GCC 13 плохо работал флаг lto, не совсем очевидно, в старших версиях не знаю, поставил llvm/clang и забыл.
Я про это и говорю, у вас нет ключей для компилятора с указанием стандарта 23, поэтому и обратил на это внимание. Необходимо либо проверять что версия gcc15 и более (здесь с23 по умолчанию) или задать ключ принудительно
Мне нравится vscode. Но в основном из-за его легкости, расширяемости и универсальности (один редактор для всего), удобством настроек в текстовом файле, а не монструозном ui
К тому же для vscode легко пишутся собственные расширения, что сильно подкупает.
Плюсую. А то окажется, что long всё равно 32 бита
Слишком много моделей данных (LLP64 например), что бы не использовать типы с указанием разрядности.
Нет никаких проблем под виндой, а wsl, как вы сказали выручает, если нужно проверить собираемость под линуксом или использовать чисто линуксовый софт. Одно огорчение было под виндой в GCC 13 плохо работал флаг lto, не совсем очевидно, в старших версиях не знаю, поставил llvm/clang и забыл.
Я про это и говорю, у вас нет ключей для компилятора с указанием стандарта 23, поэтому и обратил на это внимание. Необходимо либо проверять что версия gcc15 и более (здесь с23 по умолчанию) или задать ключ принудительно
Судя по makefile вы собираете под стандарт с11 или с17, а для них функции без аргументов должны быть с void.
Очень интересный жизненный процесс: сначала пишем, потом понимаем как работает.
Кажется что должно быть иначе: анализ проблемы, поиск вариантов решения, реализация
Если коротко по тексту:
Были проблемы..
Wiren Board молодцы, дали железяки
Wiren Board молодцы, есть дока
Интегрировали
Wiren Board молодцы
Так о чем собственно статья, где расследование, выводы, приняти решений?
С 485 дешевле и проще наклепать кучу датчиков и устройств, CAN не у всех дешевых контроллеров есть.
Был рефакторинг... Или у вас до сих пор ещё есть жабры и хвост?
Если уж на то пошло, то с таким шаблоном форматирования можно справится регулярками, благо у вас си, а не плюсы.
Заодно можно и легко отсеять все статические функции.
Умеет:
https://clang.llvm.org/docs/ClangFormatStyleOptions.html#allowallparametersofdeclarationonnextline
В чем необходимость компоновки аргументов функций именно таким образом?
Для этого можно использовать clang-format, он может генерировать отчет о несоответствии шаблону. И им же можно форматировать.
Принимайте мои соболезнования
Кодстайл и статический анализ это две разные задачи и не должны смешиваться
Зависит от стандарта языка, который вы используете. Для си >= с2х это не нужно
К слову, typedef не переопределяет тип и не создает тип, а лишь определяет псевдоним.
Да делайте, что хотите, изобретайте кучу странных скриптов и практик. Я вам показал путь без извращений, дальше сами.
Проблема с отображением затененных кусков кода это чисто проблема эклипса, в нем и нужно её решать.
Мне нравится vscode. Но в основном из-за его легкости, расширяемости и универсальности (один редактор для всего), удобством настроек в текстовом файле, а не монструозном ui
К тому же для vscode легко пишутся собственные расширения, что сильно подкупает.
Не призываю использовать, просто делюсь мнением.
Открываете настройки проекта и настраиваете провайдеры для препроцессора.
Отметил только тот который реализует функционал вашей статьи. Остальное тоже посмотрите, думаю пригодится.
Все это делается одной простой настройкой и все ваши самописные мэйкфайлы и константы из них подтягиваются и нормально отображаются а редакторе.
Под капотом эклипс делает тихую пустую сборку и уже на основе этого отображает верно.
Не нужно изобретать, нужно уметь пользоваться инструментом который выбрал.
Но, на мой взгляд, эклипс сейчас наихудший выбор для писанины кода.
Наврядли там чистый js и HTML, скорее куча плохопонимаемого кода, который если написать руками будет сильно меньше.