Здравствуйте, a7d3, Вы писали:
A>А что никак не спросить ребят из JetBrains? Почему они в своём CLion встроили поддержку Valgrind прямо из коробки, вместо других инструментов?
Оно, уже давным-давно стандарт де-факто для прыщей (линуксовых систем). Для примера, можно найти запросы на добавление поддержки Valgrind в ранние версии KDevelop в районе 2003-года.
Из недавно появившегося — стали набирать обороты санитайзеры из LLVM-овского тулчейна, но это скорее в BSD-мире и на Mac-ах, где CLang уже несколько лет как заменил GCC.
Здравствуйте, AlexGin, Вы писали:
AG>Подумал я системетизировать мои представления о программах контроля утечек памяти в проектах на C++.
Мы ловим санитайзерами, AddressSanitizerLeakSanitizer в данном случае. Главная сложность — это переловить все лики в первый раз так как приложение под санитайщерами падает сразу, как только обнаружилась проблема. А потом просто ставишь сборку под санитайзерами как часть CI, и гоняешь тесты как часть сборочного процесса, красота!
Здравствуйте, zubactik, Вы писали:
Z>Нет, изначально там все под llvm/clang. Потом добавили в GCC. Под виндой в зависимости от потребностей может и заработать сборка на clang. Z>Может ещё есть какие специфичнве требования? Ну чтобы зря не писать.
Требования — самые общие. Какой-либо специфики нет.
Преобладает — разработка в среде MSVC. Несколько реже — Qt Creator (под Linux).
Z>Так-то ещё в виде Application Verifier есть. Но пока кроме тормозов приложения никакого толку от него получить не удалось.
Здравствуйте, AlexGin, Вы писали:
... AG>Что насчет подобных средств для MSVC 2017?
...
ПРИМЕЧАНИЕ:
В среде MSVC 2017, при применении Platform Toolset v 140 (который характерен для MSVC 2015), —
отслеживание утечек памяти при помощи VLD (v 2.5.1) — работает как швейцарские часы.
Здравствуйте, AlexGin, Вы писали:
AG>Возможно, есть ещё достаточно востребованные тулзы? AG>Что насчет подобных средств для MSVC 2017?
Как основной инструмент использую umdh из Debugging Tools for Windows
Это динамическое средство анализа, позволяет выявлять heap утечки.
Инструктирование без перекомпиляции, оно встроено в системные RtlHeap* фукции.
То есть, находятся утечки malloc/new/HeapAlloc в своём и чужом коде, не находяся не-hrap утечки, такие как VirtualAlloc
Ещё использую этот же инструмент, когда утечки вроде бы нет, но всё равно хочу понять, куда делась память.
Здравствуйте, AlexGin, Вы писали:
AG>Подумал я системетизировать мои представления о программах контроля утечек памяти в проектах на C++.
AG>P.S. Гугление на данную тему, выявляет много интересных моментов. AG>Меня же больше всего интересуют популярные free-шные решения.
Можно посмотреть на встроеную в студию поддержку(кажется зависит от редакции студии), performance-monitor
Можно еще вроде с VTune поиграться(не free но триал глянуть ради интереса стоит), я его для анализа узких мест использовал, вроде там была возможность поискать утечки.
Здравствуйте, AlexGin, Вы писали:
AG>Подумал я системетизировать мои представления о программах контроля утечек памяти в проектах на C++.
Последний раз утечку памяти на С++ я видел в 2010-ом году и то только потому, что его студенты писали. Если у вас есть утечки памяти, значит вы не правильно используете С++.
Здравствуйте, B0FEE664, Вы писали:
BFE>Последний раз утечку памяти на С++ я видел в 2010-ом году и то только потому, что его студенты писали. Если у вас есть утечки памяти, значит вы не правильно используете С++.
Да я понимаю, что сейчас смарт-пойнтеры имеются (сам ими нередко усердствую) но и старый добрый new/delete иногда нужен
