Так у нас значение проинициализировнно 9.

int *i = new int(9);

Создаём int, кладём в него 9, возвращаем адрес в этого int в i.

Если что-то пошло не так, то new кидает исключение.

Не нужно там ничего проверять.

Ровно наоборот.

я вам могу показать кучу примеров на C++ которые вы даже сказать не сможете что делают.

вы наверное какой-нибудь яндексовод? ))

Пивас-студио-капец? Интересное начинание, одобряю.

Если скинемся, то так оно и будет. Собственно, давно пора, пивас достал своим унылым пеаром.

С как был так и остался нормальным языком

Да. В отличие от…

а вот C++ превратили в говно.

После того, как в С++17 впилили 2/3 (примерно) буста, стало ясно что в С++ особо больше нечего делать. Сишечка справляется и ладно.

почитайте как-нибудь по приколу https://yosefk.com/c++fqa/index.html

Ну все нормально там, это просто FAQ.

внимательнее читайте FQA секции :D :D :D

Да, мы в курсе...

Ровно наоборот.

Что, ЕМНИП, Вас где-то полгода (семестр, Вы говорили, кажется?) насиловали С. Очевидна Ваша психологическая травма. Да, так бывает. Но тут не всем «системы» и «реализации» пилить. Кому-то и клея между парочкой фреймворков за глаза.

мне кажется его просто насиловали )))

Так у нас значение проинициализировнно

Действительно. Виноват.

цели проекта научить складывать строки.

мне кажется его просто насиловали )))

Не знаю. Я не вникал особо.

Во-первых, язык сам по себе понуждает не по-детски извращаться. И тут уже дело не в том, что анализатор гуано, а в том, что код зачастую без пол-литра не разберёшь. Если следовать рекомендации «пиши проще, как на С», то тогда смысл С++ ускользает.

«Пиши проще» (с т.з. читаемости кода) - вовсе не означает «пиши как на C». Откуда вообще может появиться такая мысль?

Во-вторых. У меня лично splint подключён к vim через syntastic. Синтаксический анализ кода производится сразу при сохранении файла (можно настроить и так, чтобы при открытии производился, не проблема). И сразу формируется список ошибок (если они есть). Т.е., я сразу вижу косяки и могу их поправить до компиляции.

Ну это все понятно. По-хорошему статический анализ при использовании С++ должен быть неотьемлемой частью CI. Тут же никто не говорит, что анализаторы малополезны, потому что каждый раз IDE их запускает, и это типа время - нет, не поэтому. Проблема именно в качестве самых анализаторов и количестве ложных срабатываний. Если анализатор генерит кучу чепухи, не важно, разобьешь ли ты обработку этой чепухи на множество мелких частей, анализируемых при каждой сборке или запустишь анализатор на весь проект сразу. От перестановки слогаемых сумма не поменяется. Даже лучше разгребать авгиевы конюшни для всего проекта сразу, чем по частям - меньше переключений мозга на удовлетворение капризов анализатора.

Но это как минимум странно статическим анализатором искать ошибки, проявляющиеся в динамике.

Да, это я флейма ради приписал. Но основной посыл в том, что если ПО как следует протестировано, то львиная доля багов уже выловлена.

Опять поборы.

Палка какое-то УГ

дык. больше пронхаб не оплатить :-)

Но основной посыл в том, что если ПО как следует протестировано, то львиная доля багов уже выловлена

Вот только стоимость ловли немного разная. Заметить как IDE подчеркнула код и исправить - секунды. Весь цикл обнаружения и исправления бага - часы, если баг несложный. И всё равно остаются дремлющие баги.

Да, они мотивируют это соответствиею законам РФ.

Реальная история из недавнего, например: полдня втроем искали взрывающий мозг баг. В итоге нашли лажу в коде, которую IDE подчеркивала, но афтар не обратил внимания, или не настроил. Вот тебе и бесполезность статики.

Какой cppcheck?! Почему просто не взять Rust?

Rust

Че-то не работает ни хрена

error: expected `[`, found `include`
 --> src/lib.rs:1:2
  |
1 | #include <iostream>
  |  ^^^^^^^ expected `[`

error: aborting due to previous error

clang-tidy

Оно тащит за собой весь clang, или его можно использовать вне пределов оного?

пивас достал своим унылым пеаром

Ну пеар это последнее, что меня волнует (тем более, на ЛОРе его давно не было), а вот догнать его по фичам и впрямь не помешало бы.

Тогда лучше уж коверити. Хотя это все мечты, мечты…

Ты просто не умеешь

тащит, правда вроде не весь, но большую часть, по крайней мере в Debian: https://packages.debian.org/buster/clang-tidy-7

На Windows он устанавливается вместе с clang…

Возможно вы имели ввиду PVS Studio

Cppcheck… Закапывайте уже. Он сильно не может в C++17. Да и вообще, регулярные выражения — это тупиковый путь: https://www.viva64.com/ru/b/0087/

Используйте уж тогда бесплатный PVS-Studio (стало больше вариантов): https://www.viva64.com/ru/b/0614/

О, да. Dear PVS-Studio… помним-помним.

Закапывайте уже.

Себя закопай, толку больше будет.

да фуфел все эти статические анализаторы без исключения. многопоточный код ни один анализатор никогда не проанализирует потому что для этого код надо выполнить, и даже если код выполнить, то он может выполняться каждый раз по-разному.

valgrind выручает, остальное фуфло. все эти ваши пвс-студии, шланг-тиди и т.д, всё фуфло для лохов которые не могут написать код так чтобы по нему можно было понять есть в коде проблема или нет, а потом не могут написать юнит-тест на этот код.

хотя конечно если у вас cтуденты первого курса пишут хелловорды, то может чем-то помочь конечно.

многопоточный код ни один анализатор никогда не проанализирует

http://svr-pes20-cppmem.cl.cam.ac.uk/cppmem/

А не пытаются ли товарищи своими анализаторами решить проблему останова?

А valgrind хорош!

Да уж лучше на Раст перейти православный, чем плюсы ковырять – попрошайки одни на плюсах, куда ни кинь.

Супер-пупер продвинутая строгая статическая типизация может дать анализатору значительно больше информации, чем типизация C++. Она не является серебрянной пулей, не призвана избавить от всех проблем, не служит заменой тестированию. Но она позволяет снизить количество затраченного на отладку и тестирование времени, которое не имеет значения разве что в больной фантазии царька.

бгг. ну я же говорю, если хелловорды писать, то наверное покатит. не будет это работать, статический анализатор не может знать в какой последовательности код будет выполняться в рантайме. ну просто не будет это фуфло работать и всё, даже теоретически. на хеловордах - да, хеловорд можно сломать многими способами, а в продакшене не будет.

знаете, есть васяны которые как посмотришь на их код, андерфлоу на оверфлове, вот им такой анализатор поможет, но не сильно, потому что если человек дурак, то это анализатором не лечится, но хоть чем-то может помочь. другой вариант - заменить прокладку между креслом и клавиатурой, но это тоже не простой вопрос.

то, что вы не понимаете почему статический анализ не может покрыть рантайм о многом говорит, между прочим. в общем, я вижу по комментариям, что ваша жизнь будет наполнена болью и страданиями.

хотите облегчу страдания? забудьте про статический анализ, не надо надувать щёки, пишите на с++ как на джаве и всё будет хорошо. писать на с++ как джаве можно было ещё на с++98. забудьте про модели памяти, забудьте про SFINAE, про auto и про всё остальное, это не для вас, делайте сразу лицо попроще. для вас скоро сделают synchronized как в джаве - пользуйтесь как в джаве.

хотя конечно если у вас cтуденты первого курса пишут хелловорды, то может чем-то помочь конечно.

Как-то было выступление или статья одного разраба такого вот анализатора, в котором(-ой) он приводил примеры найденных багов у клиентов. И там действительно какой-то ахтунг был, типа #define на имена функций из стандартной библиотеки. В общем, за написание такого говнокода надо наказывать, как завещал Луговский, «не от нетерпимости, а исключительно от благородного желания ударить побольнее».

Кстати, кто-нибудь пробовал scan.coverity.com на своем опенсорсном проекте? Я пытался свой хелловорлд туда отправить, скачал ихние утилиты, которые собирают результаты анализа, отправил архивчик. В статусе проекта там что-то изменилось, типа, «проверили». И всё. А где отчет-то? Там надо как-то по особому что ли свои репозиторий оформить? Ну типа файлы с инфой о лицензиях добавить? Но в факе об этом ничего не сказано.

valgrind выручает, остальное фуфло. все эти ваши пвс-студии, шланг-тиди и т.д, всё фуфло для лохов которые не могут написать код так чтобы по нему можно было понять есть в коде проблема или нет, а потом не могут написать юнит-тест на этот код.

Тогда уж фуфло всё. Тот-же PVS видит в valgrind вот такой мёртвый код:

static
Bool doHelperCallWithArgsOnStack (....)
{
  ....
   if (guard) {
      if (guard->tag == Iex_Const
          && guard->Iex.Const.con->tag == Ico_U1
          && guard->Iex.Const.con->Ico.U1 == True) {
         /* unconditional -- do nothing */
      } else {
         goto no_match; //ATC
         cc = iselCondCode( env, guard );
      }
   }
  ....
}

В valgrind сам в себе это не видит. https://habr.com/ru/company/pvs-studio/blog/327994/

Так что спасение только одно. Применять и то и то. Тогда недостатки одного фуфла компенсируется другим фуфлом. Вот как-то так.

Вы либо оба теоретики, либо у вас отдел разработки в Гаскони. Реальные разрабы делают реальные ошибки, которые (часть которых) анализаторами ловятся. И не все они тривиальные, мало ты примеров посмотрел.

мне эти высеры про пвс-студию на хабре напоминают фокусника показывающего дешёвые фокусы. типа нашли опечатку в коде, ого, нашли строку кода которая не вызывается, ого, прямо как будто компилятор выдал предупреждение. а если я напишу if (condition), а надо было написать if (!condition), пвс-студия это обнаружит? нет? а почему? это же статический анализатор, почему бы ему не проанализировать.

ну вот например int rgba = 0;. ну явно же с запахом код, а вдруг rgba в int не влезет, а что вообще этот программист имел ввиду когда присваивал ноль - это в четыре канала или только в первый, а что насчёт endianess, ааа? ну явно же просится сюда предупреждение пвс-студии и не одно, а лучше пять. или может даже лучше сразу переписать на русте.

по поводу всех этих опечаток и невызываемых строк надо смотреть не в пвс-студию, а в историю изменений. у гита есть такая команда blaim. а спасение очень простое: ты пишешь юнит-тест, прогоняешь его под валгриндом и смотришь, что валгринд не показал ошибок. затем ты делаешь отчёт о покрытии тестами и в этом отчёте смотришь какие ветки ты на самом деле покрыл тестом, а какие не покрыл. рекомендую открыть для себя gcov/lcov, ну и, конечно, юнит-тесты надо, сцуко, не только писать, но ещё и читать.

вот такой статический анализ.

Так они и задачи такой не ставят, анализировать логику программы - это же проблемой останова попахивает. Эти статические анализаторы C++ просто указывают места в программе, которые могу привести к проблемам. А могут и не привести.

Реальные разрабы делают реальные ошибки, которые (часть которых) анализаторами ловятся.

Тот разраб, который printf #define’ом подменил тоже реален. И что?

а зачем брать этот всратый недоязычек?

На нём и после тебя будут писать, прикинь :)

ну я ж не против. просто это подаётся под таким соусом типа «пришло спасение, нашёлся анализатор который нашёл пропущенную звёздочку».

и никого вообще не смутило, что сравнение char * и char сконпелировалось без предупреждений? а может оно сконпелировалось с предупреждением или даже с ошибкой, просто никто не проверил? а что если взять вот этот код с хабра и скопипастить его в godbolt, то что получится?

Покажи типизацию мощнее оной в C++.

не будет это работать, статический анализатор не может знать в какой последовательности код будет выполняться в рантайме

Ты клинический идиот, да? Оно перебирает все возможные последовательности выполнения в рантайме.

Говно этот ваш cppcheck

Кстати, вот на такой код cppcheck ругается, так что кое-что он пытается искать, но пока плохо конечно:

#include <iostream>

int main()
{
    int *i = new int(9);
    if (*i)
        std::cout << *i << std::endl;
    delete i;
    std::cout << *i << std::endl;
    return 0;
}

https://imgur.com/a/yYKPYhy

Да я разное видел.

«Пиши проще» (с т.з. читаемости кода) - вовсе не означает «пиши как на C». Откуда вообще может появиться такая мысль?

Встречались и такие «клованы» (даже «клоунами» назвать сложно).

По-хорошему статический анализ при использовании С++ должен быть неотьемлемой частью CI.

А отчасти так и есть. Если посмотреть на опции gcc/gpp/g++, то там уже многое сделано для защиты от дурака при компиляции. Та же поддержка fortify source или ASLR. Тот же splint для С это просто «система раннего предупреждения». Злобность системы так же настраивается. Там… большая дока на splint.

Проблема именно в качестве самых анализаторов и количестве ложных срабатываний

Splint можно ограничить в его злобности, есть такое. Можно даже предупредить что, мол, я знаю что здесь ты будешь орать, но так надо, не обращай внимания. Т.е., ответственности программиста за косяк (даже потенциальный) ни кто не снимает. Просто потому, что ни один анализатор не берётся за семантику программы. Максимум что – он может «свистнуть» типа возможен buffer overflow, например. Или переменные не инициализированы. Но ждать от него чудес… Не знаю. Не хотел бы я чтоб за меня анализатор ещё и код правил. =)))

Даже лучше разгребать авгиевы конюшни для всего проекта сразу, чем по частям - меньше переключений мозга на удовлетворение капризов анализатора.

Это кому как. Я проверяю автоматом, при сохранении файла сырцов. Потом, конечно, весь проект «продираю» splint’ом. Но если сразу есть «стук», то я лично сразу предпочитаю его поправить. В сумме качество кода выше получается.

Но основной посыл в том, что если ПО как следует протестировано, то львиная доля багов уже выловлена.

Про флейм понятно. =) А так-то, TDD или отдельное тестирование ни кто и не отменял и не собирается. Хотя, видел я клованов, которые утверждали что безглючных проектов не бывает. Чем они заканчивали, тоже видел. =)))

Собственно, анализатор это такая тулзень, которая может «ткнуть пальчиком» в строчку в коде и задать вопрос типа «чувак, ты хорошо понимаешь что, как и зачем ты написал?» и не более. =)

Непрерывный статический анализ кода

Но основной посыл в том, что если ПО как следует протестировано, то львиная доля багов уже выловлена.

Верно. Однако статический анализатор, это предварительный грубый отсев. Это грубое решето, применяемое на самом раннем этапе. Вот в чём его смысл. Можно быстро сразу найти часть ошибок. Это дешево. Можно найти их и потом, но это дороже. Хорошо и правильно про идеологию рассказывается здесь: Иван Пономарёв. Непрерывный статический анализ кода: https://youtu.be/_Wv-PvZeRlI Очень хорошее видео.