Комментарии 28
НЛО прилетело и опубликовало эту надпись здесь
Жаль, что не попало ничего из серии if (a != 1 && a != 2), помню, когда нашел такое анализатором, то было очень смешно :)
А что здесь не так?
Скорее всего, имелось ввиду (a != 1 || a != 2) либо его производные выражения через отрицание.
always true/always false, зачастую встречается даже в серьезном коде, те же resharper/студия( в c#) сильно не всегда отлавливают, особенно если предикат длинный.
always true/always false, зачастую встречается даже в серьезном коде, те же resharper/студия( в c#) сильно не всегда отлавливают, особенно если предикат длинный.
Кстати хороший вопрос. Если 1, или 2 — false, если что-то другое — true.
Да, конечно же имелось в виду if (a != 1 || a != 2).
Ясно же, «А» заглавная!
Была у меня статеечка на эту тему: Логические выражения в C/C++. Как ошибаются профессионалы. В один год я увидел слишком много таких ошибок и решил собрать все типы в один документ.
В пятом случае ошибки нет, статический член catalog инициализируется корректно — проверка
В четвертом случае, при передаче POD типов, разницы между delete и delete[] тоже нет.
Но с копи-пастой борьба успешная =)
В четвертом случае, при передаче POD типов, разницы между delete и delete[] тоже нет.
Но с копи-пастой борьба успешная =)
В любом случае
А можно пояснить, как в случае №5 код соотносится с описанием «проблемы»? В конструкторе G4PhysicsModelCatalog создается статический объект типа modelCatalog, указатель на который сохраняется в статическом же члене класса. Такое впечатление, что разработчики хотели достичь того, чтобы экземпляр modelCatalog создавался бы только при создании первого экземпляра G4PhysicsModelCatalog. Если же G4PhysicsModelCatalog нет, то нет и экземпляра modelCatalog.
Про delete и delete[] в 4 примере поясните, пожалуйста, с какой стати нет разницы для POD-типов.
Товарищи вот тут http://stackoverflow.com/questions/4255598/delete-vs-delete цитируют стандарт, где ясно сказано про undefined behaviour.
P.s. в 3 примере вообще, скорее всего, было бы уместно
std::unique_ptr<int[]> ss(new int[decks * 52]);
(хотя без полного кода не скажешь, конечно).
Потому что delete[] дополнительно вызывает деструкторы каждого объекта массива. Других отличий от delete нет.
У POD типов нет деструкторов, так что вызывать нечего.
Но для классов я бы не пренебрегал [], т.к. классы могут и переделать когда нибудь потом другие люди. Но в примере простой int
У POD типов нет деструкторов, так что вызывать нечего.
Но для классов я бы не пренебрегал [], т.к. классы могут и переделать когда нибудь потом другие люди. Но в примере простой int
Давайте анализаторы для Go & TypeScript!
А как вы вообще находите примеры ошибок, которые можно искать. Вам их присылают?
Еще раз убедился в том, что ошибка при копипасте — это популярная ошибка.
которое может, например, привести к аварийному завершению программы.
Скорее всего по глобальной логике программы переменная типа ViewEdge всегда является и FEdge тоже, поэтому ошибка ни к чему привести не может. Просто мелкая неаккуратность.
Такой программы давно нахватало, ведь программировать что-что сложно, а находить ошибки в коде ещё сложней (особенно если исправляешь программу человека который не хочет разбираться, а старается «пробиться» и самому не делать, так и хочется сказать потом «на, подавись!», но воспитанность не позволяет, а тут на бери не хочу и пользуйся в своё удовольствие).
С макросами и FreeBSD порадовало. Помнится сам измучился с макросами когда студентом был, позвал начальника, и он сказал очень простое правило — каждый параметр макроса внутри макроса обязательно брать в круглые скобки, а так же использовать не более одного раза. Такая минимальная осторожность позволяет никогда не факапиться!
Недавно проверил код эмулятора Nestopia. Нашлись несколько ошибок и несколько подозрений на ошибки, но нужно было сильно разбираться в коде, чтобы понять, действительно ли ошибки или ложные подозрения. Например, функция ширины спрайта возвращает координату левого края. Анализатор предупреждает, что тело функции соответствует функции получения левого края. Приятно, что о таком предупреждает.
А вот когда предупреждает про одинаковое тело просто метода и const метода — огорчает. Может стоит дополнить правило, что если у методов одинаковые имена и списки аргументов, но различный const у возвращаемого значения и самого метода, то для них не предупреждать об одинаковом теле?
А вот когда предупреждает про одинаковое тело просто метода и const метода — огорчает. Может стоит дополнить правило, что если у методов одинаковые имена и списки аргументов, но различный const у возвращаемого значения и самого метода, то для них не предупреждать об одинаковом теле?
вот когда предупреждает про одинаковое тело просто метода и const метода — огорчает. Может стоит дополнить правило, что если у методов одинаковые имена и списки аргументов, но различный const у возвращаемого значения и самого метода, то для них не предупреждать об одинаковом теле?Если я всё правильно понял, то такого срабатывания быть не должно. Прошу привести синтетический пример, на котором воспроизводится ложное срабатывание. Можно в почту.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Топ 10 ошибок в открытых проектах С++ за 2016 год