Как-то вы моментально согласились и ответили (учитывая, что мой комментарий содержит ссылки на другие материалы). Вы случайно не бот? ) Что-то у меня с доверием плохо стало... )
Вы всё-таки не представляете сложность и трудоёмкость подобных мероприятий :) В 2025 целая группа компаний пыталась испытать анализаторы кода. И за год не успели сделать то, что хотелось. А тут кто-то раз и сравнит/исследует в разрезе LLM... )
Впрочем, я понимаю, что вы имеете в виду. Я то про основательный подход. А вы про хоть какие-то тесты. Но к сожалению такие тесты оставляют слишком много места для спекуляции и кто захочет, сможет всё вывернуть в ту сторону, которую хочется. По этому нет желания во всё это погружаться. Всё равно пока волна хайпа не прокатится, будет какая-то бессмысленная борьба с ветряными мельницами (хоть и старый пост, но пример излишнего энтузиазма - GPT-3 нашёл 213 Security Vulnerabilities... Или не нашёл).
Кстати, а ChatGPT 5.2 именно эти 2 строчки предложил добавить? Или там ещё рядом template <typename T> был? Потому, что если только эти две, то это белиберда, вернее неудачная попытка создать:
Эта переменная была нужна в качестве обходного пути до P2593R1 (С++23): static_assert требовал выражение, зависящее от типа, чтобы не прерывать компиляцию в случае валидной специализации шаблона. Если используются компиляторы GCC >= 13, Clang >= 17 или MSVC >= 19.40, то более так писать не нужно: код компилируется и с более старыми версиями стандартов.
Приветствую, я в последние года реже стал заходить в на хабр, но приятно видеть некотое постояноство в виде ваших постов.
Спасибо :)
Я могу пропустить, но вы не делали анализ какой какой процент найденых предупреждений находят различные LLM модели??
Не делали, так как это сложнее, чем кажется. Ведь одно дело сунуть кусок и сказать, а есть ли здесь ошибочка? И совсем другое – взять реальный проект и понять, насколько эффективна LLM ищет ошибки, отделяя их от галлюцинаций. Т.е. это огромная работа с непонятным профитом. Ибо через полгода выйдет что-то новое и все будут говорить, ну, это раньше было, проведите сравнение с новой моделью...
У вас же есть подмножество таких предупреждений которые изолированные в отдельном не очень большом куске куда. Был бы замечательный бенчмарк.
Вот в том-то и дело, что одно дело тестирование на изолированных примерах и совсем другое, на реальном коде, где LLM начинают правдоподобно описывать проблемы, которых нет. Это классический статический анализ приблизительно одинаково (детерминировано) ведёт себя, что на коротких, что на длинных примерах. А попробуй LLM попросить рассказать, что не так с большой функцией... :)
но ситуация еще в том, что строки лучше создать 1 раз может быть
Суть именно в "может быть" :) Не всё что может быть оптимизировано, должно быть оптимизировано :) Дополнительная оптимизация здесь имеет смысл, если только этот код действительно выполняется много раз.
А ещё не факт, что сильно удастся оптимизировать. Здесь короткие строки и скорее всего уже используется Small String Optimization (SSO). Вместе с оптимизациями компилятора это может вообще и так уже очень хорошо работать.
P.S. Немного в сторону, но возможно кому-то будет инетресно. Как раз недавно оптимизации, связанные со строками, обсуждали на вебинаре: Оптимизация игр: работа со строками.
Представленный фрагмент кода на языке C++ описывает шаблон структуры NumericParameter, которая наследуется от некоторого базового класса Parameter. Шаблон параметризуется типом T, который используется внутри структуры как ValueType.
Метод name() в этой структуре использует серию проверок с помощью if constexpr и std::is_same_v для определения типа ValueType и возвращает соответствующую строку, представляющую имя типа данных. Если тип не соответствует ни одному из указанных в условных операторах, генерируется ошибка компиляции с помощью static_assert.
Как-то вы моментально согласились и ответили (учитывая, что мой комментарий содержит ссылки на другие материалы). Вы случайно не бот? ) Что-то у меня с доверием плохо стало... )
Вы всё-таки не представляете сложность и трудоёмкость подобных мероприятий :) В 2025 целая группа компаний пыталась испытать анализаторы кода. И за год не успели сделать то, что хотелось. А тут кто-то раз и сравнит/исследует в разрезе LLM... )
Впрочем, я понимаю, что вы имеете в виду. Я то про основательный подход. А вы про хоть какие-то тесты. Но к сожалению такие тесты оставляют слишком много места для спекуляции и кто захочет, сможет всё вывернуть в ту сторону, которую хочется. По этому нет желания во всё это погружаться. Всё равно пока волна хайпа не прокатится, будет какая-то бессмысленная борьба с ветряными мельницами (хоть и старый пост, но пример излишнего энтузиазма - GPT-3 нашёл 213 Security Vulnerabilities... Или не нашёл).
Кстати, а ChatGPT 5.2 именно эти 2 строчки предложил добавить? Или там ещё рядом
template <typename T>был? Потому, что если только эти две, то это белиберда, вернее неудачная попытка создать:Эта переменная была нужна в качестве обходного пути до P2593R1 (С++23):
static_assertтребовал выражение, зависящее от типа, чтобы не прерывать компиляцию в случае валидной специализации шаблона. Если используются компиляторы GCC >= 13, Clang >= 17 или MSVC >= 19.40, то более так писать не нужно: код компилируется и с более старыми версиями стандартов.Спасибо :)
Не делали, так как это сложнее, чем кажется. Ведь одно дело сунуть кусок и сказать, а есть ли здесь ошибочка? И совсем другое – взять реальный проект и понять, насколько эффективна LLM ищет ошибки, отделяя их от галлюцинаций. Т.е. это огромная работа с непонятным профитом. Ибо через полгода выйдет что-то новое и все будут говорить, ну, это раньше было, проведите сравнение с новой моделью...
Вот в том-то и дело, что одно дело тестирование на изолированных примерах и совсем другое, на реальном коде, где LLM начинают правдоподобно описывать проблемы, которых нет. Это классический статический анализ приблизительно одинаково (детерминировано) ведёт себя, что на коротких, что на длинных примерах. А попробуй LLM попросить рассказать, что не так с большой функцией... :)
Суть именно в "может быть" :) Не всё что может быть оптимизировано, должно быть оптимизировано :) Дополнительная оптимизация здесь имеет смысл, если только этот код действительно выполняется много раз.
А ещё не факт, что сильно удастся оптимизировать. Здесь короткие строки и скорее всего уже используется Small String Optimization (SSO). Вместе с оптимизациями компилятора это может вообще и так уже очень хорошо работать.
P.S. Немного в сторону, но возможно кому-то будет инетресно. Как раз недавно оптимизации, связанные со строками, обсуждали на вебинаре: Оптимизация игр: работа со строками.
Кстати:
Ещё один проигравший :)
Зачем писать плохой код и потом подпирать его костылями? Этот код всё равно притягивает ошибку (есть переносы в редакторе или нет), и притянул.
Кто мешает в команде использовать свой стандарт кодирования?
Продолжение - Подножка для AI в виде UTF-8.
Ну что мы всё неправильно делаем, нам уже лет 15 рассказывают :) Вспомнились старые времена: Народ против PVS-Studio: дубль первый :)
Вебинар 4. Управление конфигурацией программного обеспечения.
Вебинар 5. Управление недостатками и запросами на изменение программного обеспечения.
Вебинар 6. Разработка, уточнение и анализ архитектуры программного обеспечения.
Некоторые уточнения про список критических ошибок, а заодно, как их фильтровать: Фильтрация предупреждений PVS-Studio, выявляющих критические ошибки (согласно классификации ГОСТ Р 71207-2024)
Продолжение:
Испытания статических анализторов (стр. 72)
Итоги этапа «Домашнее задание» испытаний статических анализаторов под патронажем ФСТЭК России
Мой комментарий про этам "Домашнее задание"
Продолжение истории про жизнь ГОСТ Р 71207—2024:
ФСТЭК России объявила о начале масштабных испытаний статических анализаторов
Испытания статических анализторов (стр. 72)
Итоги этапа «Домашнее задание» испытаний статических анализаторов под патронажем ФСТЭК России
Мой комментарий про этам "Домашнее задание"
Собрали не в PDF, а в бумажную книгу "Экскурс в неопределенное поведение C++". Можно найти в offline и online магазинах.
Переработанный и дополненный вариант этой подборки про UB стал доступен в виде бумажной книги. Подробнее.
Совпадение (а может и нет :). Вот какую статью мы сегодня опубликовали - PVS-Studio доступен в OpenIDE.
Запись третьего вебинара - Процесс 3: Формирование и предъявление требований безопасности к программному обеспечению.