Pull to refresh

Comments 18

Да, чёрно белые фотки как-то сейчас уже не то… :)
Человек фотографировал без вспышки, чтобы не беспокоить людей.
Это я такое фото поставил. Честно говоря, искал в интернете качественный крупный вариант, побольше аватарки, не нашел, взял из фотографий Стаса Давыдова. А он соответственно, обнаружив, что фото шумят, (нет, чтобы обработать шумодавом!), сделал их черно-белыми.

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

Кстати спасибо за видео, сделано очень качественно. Наилучший скринкаст (технически) из тех, что мне попадались. Очень качественно реализовано.
Статический анализ должен быть частью компилятора
Ну… Это не такой уровень — ваш продукт лучше находит.

А сравнение с clang есть?
Сейчас нет. Но мы готовы к совместной статье по сравнению. Будет замечательно, если в сравнении поучаствует независимый человек. В противном случае, на любую нашу статью будут смотреть предвзято. Если Вы действительно заинтересованы в данной тематике, то давайте подумаем какие проекты можно совместно проверить и формат статьи. Прошу в личную почту.
Ваш инструмент вроде как с Objective-C кодом не умеет работать. А у clang на сколько я понимаю это самая сильная сторона.
не самая, а одна из многих
это было бы интересно, но я не уверен, что мой уровень сейчас достаточен. Вот как наберусь сил
Хотелось бы узнать мнение авторов PVS-Studio, или людей активно использующих различные статические анализаторы года по поводу: «Наскока это полезно, если я *уже* использую valgrind?»
Valgrind это представитель динамических анализаторов. У динамического и статического анализа есть свои преимущества и недостатки.

Преимущества статического анализа перед динамическим:

1) Статический анализ проверяет весь код. Вы можете проверить даже те ветви, которые крайне редко получают управления. Выполнить определенные ветви программы в процессе её работы бывает очень трудно (сложно подготовить данные, сложно сымитировать аварийную ситуацию и так далее).

2) Динамический анализ часто пасует при тестировании ресурсоемких приложений. Если программа перемалывает гигабайты данных, то внедрение динамического анализатора может привести к недопустимому снижению скорости работы. То есть всё будет работать, вот только ждать надо неделю. Статический анализ не зависит от этапа исполнения, так как анализирует исходный код. При этом его скорость анализа легко и просто масштабируется.

3) Вы можете проверить код в тот момент, когда запуск определенных тестов еще невозможен. Это значит, что мы устраняем некоторые ошибки максимально рано, а значит максимально дёшево.

4) Статический анализатор может выявить ситуации, совершенно безопасные с точки зрения динамического анализа. Простейший пример.
class MyArray()
{
  std::vector m_arr;
  ...
  void DeleteAll() { m_arr.empty(); }
  ...
};


С точки зрения динамического анализа, DeleteAll вполне себе хороший метод. Он ничего не портит. А вот статический анализатор замечает и предупреждает о странной конструкции — результат m_arr.empty() не используется.

P.S. Статический анализ не конкурент динамическому. Они отлично дополняют друг друга.
К верификации в целом есть некоторые вопросы. Много обнадеживающих научных статей на эту тему, но в индустрии видно мало выхлопа (почему — то же интересно). В основном, в проектах вроде ПО для спутников, военных и так далее. Интересны перспективы этого направления CS в широкой индустриальной разработке.
ps пример с auto_ptr в chrome — методологичнее советовать использовать unique_ptr нежели boost::scoped_ptr.
а то так и не узнают люди про с++0х. все еще бетту студии (09 год) используют, мда.
Выхлоп есть. Скорее просто мы его не видим. В России использование статического анализа это что-то скорее экзотическое. Мало достаточно больших компаний с серьезными внутренними процессами. Вот и кажется, что он не используется. На западе же статический анализ привычное дело.
Андрей, а как вы выбираете правила для анализатора? Есть ли какая-то система, или вы основываетесь на личном опыте?

Не думали использовать symbolic execution?
Сейчас у нас есть большой TODO список где описаны различные ситуации, которые следует научиться диагностировать. Список составлен и пополняется на основе личного опыта, присланных на почту примеров, вычитанного в статьях, вычитанного в стандартах кодирования и так далее. Что именно реализовать в следующую очередь, сейчас выбирается в общем то хаотично. :) Поле не пахано во всех направлениях…

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

Symbolic execution уже имеется в зачаточном состоянии. Постепенно будем развивать это направление. Например, сейчас мы можем догадаться вот здесь об опасности:

void F()
{
  const size_t N = 10;
  int A[N];
  for (size_t i = 0; i != N; ++i)
  {
    A[i] = 0; //ok
    
    A[i + 1] = 0; //V557: Array overrun is possible.
                  //The value of 'i + 1' index could reach 10.
    
    if (i < 3)
      A[i + 1] = 0; //ok
  }
}


Sign up to leave a comment.