Не совсем понял, что вы имеете в виду под "необходимость синхронно поддерживать и использовать одни и те же режимы компиляции исходных текстов программ" в той части, где пишете про использование статического анализа?
Google, например, не смотря на стратегию перехода на Memory safe языки (e.g. Rust) в новых проектах продолжает развивать сторонние инструменты, делающие разработку на C++ более безопасной.
Безусловно процесс разработки важен при разработке на любом языке, но в мире С++ эта проблема стоит особенно остро, потому сам язык очень сложный, многие вещи можно делать разными способами. Вот например проверки clang-tidy группы modernize-* будут требовать использования более современных вариантов решить одну и ту же задачу на C++: modernize-avoid-bindmodernize-avoid-bind modernize-avoid-c-arrays modernize-use-auto В других языках скорее всего просто не будет возможности написать код 5 разными вариантами. Плюс в С++ многих полезных инструментов нет "из коробки", как например в Rust или Go.
Как видите, разработка умных устройств — это не только «хардкорный embedded». Разработка приложений для девайсов в том числе ведется на современном C++ с использованием инструментов статического и динамического анализа кода.
Чтобы успешно разрабатывать большой проект на языке C++, необходимо хорошо настроить процесс разработки в команде (а у нас это несколько десятков инженеров). Также можно значительно осовременить разработку на C++ за счет использования подходящих инструментов статического и динамического анализа и правильной интеграции их в процесс разработки.
Из перечисленных альтернатив мы интересовались только Rust, но действительно большое количество профессиональных разработчиков на локальном рынке - это может и не единственный, но главный фактор, второй фактор - это максимальная переносимость кода, хотя у Rust в этом плане все неплохо, но нам важно чтобы мы могли интегрироваться буквально в любую кофеварку. Про bounds-safety, кстати, в последнем clang-tidy 18 есть новая проверкаbugprone-unsafe-functions, но мы ее пока не пробовали, у нас пока версия 15.
По поводу использования исключений ответ есть в Google C++ Code style: On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code Наш проект относительно новый (по меркам других C++ проектов с многолетней историей), и мы используем исключения, потому что это удобно. Какие еще темы были бы интересны?
У вас не проходит пулл-реквест если формат неверный?
Да, если формат не верный, Pull Request не пройдет. Обычно ошибки форматирования находятся еще раньше, так как также настроена интеграция clang-format в используемых IDE и при сохранения файла он будет сразу отформатирован и дополнительно еще есть локальный git-hook который обнаружит проблему до того, как будет создан PR. Тогда можно вызывать команду, которая исправит форматирования в измененных файлах автоматически. Автоформатирование после коммита мы не делаем, потому что не нужно и рискованно менять код после коммита
Не совсем понял, что вы имеете в виду под "необходимость синхронно поддерживать и использовать одни и те же режимы компиляции исходных текстов программ" в той части, где пишете про использование статического анализа?
Google, например, не смотря на стратегию перехода на Memory safe языки (e.g. Rust) в новых проектах продолжает развивать сторонние инструменты, делающие разработку на C++ более безопасной.
Предупреждение будет при объявлении структуры, его нужно будет отключить. При приведении указателя к типу структуры предупреждения не будет.
Мы у себя рекомендуем всегда указывать явно тип отключаемого предупреждения в скобках.
Безусловно процесс разработки важен при разработке на любом языке, но в мире С++ эта проблема стоит особенно остро, потому сам язык очень сложный, многие вещи можно делать разными способами.
Вот например проверки clang-tidy группы modernize-* будут требовать использования более современных вариантов решить одну и ту же задачу на C++:
modernize-avoid-bindmodernize-avoid-bind
modernize-avoid-c-arrays
modernize-use-auto
В других языках скорее всего просто не будет возможности написать код 5 разными вариантами.
Плюс в С++ многих полезных инструментов нет "из коробки", как например в Rust или Go.
Смотрели как исключения влияют на размер бинарного файла с помощью bloaty, размер секции .gcc_except_table составлял около 3%:
Из перечисленных альтернатив мы интересовались только Rust, но действительно большое количество профессиональных разработчиков на локальном рынке - это может и не единственный, но главный фактор, второй фактор - это максимальная переносимость кода, хотя у Rust в этом плане все неплохо, но нам важно чтобы мы могли интегрироваться буквально в любую кофеварку.
Про
bounds-safety, кстати, в последнем clang-tidy 18 есть новая проверка
bugprone-unsafe-functions, но мы ее пока не пробовали, у нас пока версия 15.По поводу использования исключений ответ есть в Google C++ Code style: On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code
Наш проект относительно новый (по меркам других C++ проектов с многолетней историей), и мы используем исключения, потому что это удобно.
Какие еще темы были бы интересны?
Да, если формат не верный, Pull Request не пройдет.
Обычно ошибки форматирования находятся еще раньше, так как также настроена интеграция clang-format в используемых IDE и при сохранения файла он будет сразу отформатирован и дополнительно еще есть локальный git-hook который обнаружит проблему до того, как будет создан PR. Тогда можно вызывать команду, которая исправит форматирования в измененных файлах автоматически.
Автоформатирование после коммита мы не делаем, потому что не нужно и рискованно менять код после коммита