Jakub NerudaIt is hard to justify usage of clang-tidy when it takes longer than clean compilation of analyzed project.
Certainly not on each compile, when it takes few minutes to complete (on measly 37 files) 😞
Gareth Lloyd (He/him)[EDIT: this is wrong, read thread]
Interesting #clangtidy issue.
When using #cppmodules its possible to have a fixit applies multiple times causing incorrect code.
I believe what is happening is the cppm is the source text, but its analysed in other translation unit by the module import which uses its pcm. In parallel they both read and apply their fixit and you get situations like NULL becoming nullptrptr.
I'll try and make a minimal example at some point.
аккаунт более неактивенКак на счёт того, что на работу надо нанимать лишь профессионалов с должным уровнем знания языков программирования?
А не тех, кто считает, что этот код выведет −1.
#include <vector>
#include <numeric>
#include <iostream>
int average(const std::vector<int>& v) {
if (v.empty()) {
return 0;
}
return std::accumulate(v.begin(), v.end(), 0) / v.size();
}
int main() {
std::cout << average({-1,-1,-1});
}Если не верится, то https://godbolt.org/ в помощь.Будучи собрано GCC или Clang для систем x86-64 оно выведет: 1431655764.
Ирония постиронией, а вот не смешно ни разу, поскольку никакой Clang-Tidy такого «не ловит» bugprone-narrowing-conversions.
(извиняюсь за Керниган-Ричччи си-шный стиль в расстановке фигурных скобок, но так компактнее).
#программирование #C++ #С++ #Cpp #programming #softdev #staticanalysis #ClangTidy @russian_mastodon @Russia
KDABClang-tidy helps modernize C/C++ code by detecting bugs, inefficiencies & outdated patterns. While setup can be tricky, it's a powerful ally for migrating large codebases to modern C++. #Cpp #ClangTidy #StaticAnalysis #CodeQuality
https://www.youtube.com/watch?v=EWq4mXjeDV8
https://www.youtube.com/watch?v=EWq4mXjeDV8
C++ Applications Architecture Best Practices: Migrating to New C++ Standards with Clang-tidy
Mathias HasselmannWhen you spot such warnings after waiting endlessly for clang-tidy: "Suppressed 48487 warnings (48482 in non-user code, 5 NOLINT).
So, to tell me about suppressed warnings in non-user code you must have checked it. But seriously nobody cares, dear clang-tidy. Are you German, or what's your problem?
grumbНаблюдая за публикациями и выступлениями Андрея Карпова из PVS-Studio постоянно ловил себя на фейспалме. Особенно, когда этот человек бегал по LinkedIn и набивался в друзья ко всем подряд.
И вот никогда не сомневался, что в своём падении такой человек может пойти дальше. Нисколько не останавливаясь и не тормозя пробить «дно-днище» не одно и не два сразу.
В чём лишний раз и убедился полистав его очередной опус — аж целую книжку: «Вредные советы для C++ программистов»
Давненько не доводилось видеть столь убогой работы в плане вёрстки и типографики. Настоящая колхозная самодеятельность 21-го века.
За суть и содержимое не подскажу, чувство гадливости напрочь отшибает любое желание погружаться в контент.
Спасибо, Андрей, что про продолжаешь радовать и тешить нас! Настоящий со-учредитель и успешный бизнесмен ИТ-сектора, стоящий на страже качества и надёжности АИС!
P.S. Мы как пользовались #ClangTidy да #CppCheck так и продолжим, не потому что #PVSStudio плохой продукт, а из-за того, кто и как его пиарит, кто за ним стоит (в твоём лице).
HabrБезопасная работа с итераторами в С++
После публикации предыдущей статьи на данную тему, некоторые читатели не обратили внимания, что данный проект, это не действующий инструмент, готовый для боевого применения в реальных проектах, а только доказательство работоспособости концепции использования плагинов компилятора для дополнительного семантического контроля исходного кода С++ во время компиляции. А в качестве примера реализации подобного плагина я взял концепцию безопасной работы с памятью из языка NewLang с минимальной адаптацией под C++ . То есть основная идея предыдущей статьи — продемонстрировать возможность использования плагина компилятора для дополнительного анализатора исходного текста, а не изучение функциональности реализованной библиотеки для работы с памятью (которая и не может быть в полном объеме портирована на С++ из-за архитектурных различий в этих языках программирования). Тем не мене, большинство читателей все же уловило основную мысль и проявило интерес к возможному дальнейшему развитию подобного подхода к повышению безопасной разработки на С++ без нарушения обратной совместимости со старым кодом. Поэтому, чтобы не смущать читателей отсылкой к неизвестному для них новому языку, я начал адаптировать концепцию безопасной работы с памятью под чистый С++ для решения специфических для С++ проблем. А пока идет доработка плагина и мне очень захотелось поделиться одним очень увлекательным квестом, которой показывает непреодолимые архитертурыне проблемы С++ на пути к безопасному программирования. И поводом для того стали итераторы.
https://habr.com/ru/articles/878156/
#clang #clangtidy #plugin #memory_management #memory_safety #iterator
Безопасная разработка на С++ без нарушения обратной совместимости. Библиотека MemSafe и плагин для Clang
Статья в продолжение темы безопасной разработки на С++ с примером работающего кода. Кратко предыдущие тезисы: Стремление С++ стать более "безопасным" языком программирования плохо сочетается с требования к стандарту языка. Ведь любой стандарт должен обеспечивать обратную совместимость со старым легаси кодом, что автоматически сводит на нет любые попытки внедрения какой либо новой лексики на уровне единого стандарта С++. А раз текущее состояние С++ не может гарантировать безопасную разработку на уровне стандартов, то выходит, что: Принятие новых стандартов С++ с изменением лексики для безопасной разработки обязательно нарушат обратную совместимость с существующим легаси кодом. Переписать всю имеющуюся кодовую базу С++ под новую безопасную лексику (если бы такие стандартны были приняты), ничуть не дешевле, чем переписать этот же код на новом модном языке программирования. Возможным выходом из данной ситуации является реализация такого синтаксиса безопасного С++ , который бы позволил удовлетворить оба этих требования. Причем самый лучший вариант, вообще не принимать какие либо новые стандарты С++ для изменения лексики, а попробовать использовать уже существующие принятые ранее.
https://habr.com/ru/articles/874648/
#clang #clangtidy #plugin #memory_management #memory #safety
Безопасная разработка на С++ без нарушения обратной совместимости. Библиотека MemSafe и плагин для Clang
Статья в продолжение темы безопасной разработки на С++ с примером работающего кода. Кратко предыдущие тезисы: Стремление С++ стать более "безопасным" языком программирования плохо сочетается...
Безопасная разработка на С++ без нарушения обратной совместимости с легаси кодом
Проблема безопасной разработки на С++ возникла не вчера, и она достигла таких размеров, что рекомендации использовать более надежные языки программирования , принимаются на самом высоком уровне. Но даже несмотря на наличие подобных рекомендаций, планы прекратить использовать С++ и перейти любой другой безопасный язык программирования, часто не выдерживают обычных финансовых расчетов. Ведь если отказаться от С++, то что придется делать с миллионами или даже миллиардами строк кода, которые были написаны за несколько предыдущих десятилетий? К сожалению, и сам С++ не особо стремится стать более "безопасным". Точнее, подобное стремление плохо сочетается с требования к стандарту языка, которые принимаются комитетом по стандартизации С++. Ведь любой стандарт должен обеспечивать обратную совместимость со всем старым легаси кодом, что автоматически сводит на нет любые попытки внедрения какой либо новой лексики на уровне единого стандарта С++. И в это ситуации правы те, кто выступает за обязательную поддержку обратной совместимости со старым кодом. Но правы и те, кто считает необходимым добавление новых возможностей для безопасной разработки на С++ хотя бы в новых проектах. Таким образом, возникают, казалось бы , взаимоисключающие и не разрешимые противоречия: Текущее состояние С++ не может гарантировать безопасную разработку на уровне стандартов языка. Принятие новых стандартов С++ с изменением лексики для безопасной разработки обязательно нарушат обратную совместимость с существующим легаси кодом. Переписывать всю имеющуюся кодовую базу С++ под новую безопасную лексику (если бы такие стандартны были приняты), ничуть не дешевле, чем переписать этот же код на новом модном языке программирования. Но ключевым моментом в предыдущем абзаце является фраза "казалось бы".
https://habr.com/ru/articles/872956/
#clang #clangtidy #plugin #memory_management #memory #safety
C++ on SeaBuilding on clang-tidy to Move From printf-style to std::print-style Logging and Beyond – by @mikecrowe
