Мне сейчас довольно тяжело будет снова настраивать проекты под студию. У нас для всех проектов, и виндовых, и линуксовых используется система сборки QBS. Но я слежу за вашим проектом внимательно, и обязательно попробую еще раз, как только будет чуть посвободнее график (сейчас только срочняки в очереди).
Кстати, раз на то пошло — по результатам разных анализов стат.анализаторов (pvs, cppcheck, clang) — самая распространенная ошибка в моем проекте — неинициализированное поле (в том числе указатель). потенциальное *null лишь на втором месте.
Таких ошибок, как «эффект последней строки» или «эффект копипасты», почему-то ненаблюдалось. Обычно они очень быстро вылазят при первом же прогоне/тесте.
Ну еще довольно частые незначительные ошибки смешниваия int/size_t/uint32_t при доступе к контейнерам (при сериализации — нет).
Вот такая статистика =)
Да, ни один из стат анализаторов, к сожалению, не нашел ошибки, которая реально могла бы привести к порче/потере данных (потенциально, при каком-то дальнейшем изменении кода — да). Нет, не то что у нас прямо так идеально код пишут, я считаю, что то что было найдено- тоже полезно. Но больше с точки зрения прикладной диагностики принес нам valgrind (да, я читал ваши статьи про отличия динамического и статического анализа и понимаю что они мало где пересекаются).
Раз уж я рассказываю о своем опыте, опишу самый распространенный класс ошибок, найденный valgrind — выделяется память, сохраняется указатель, и потом передается через очень долгие и тернистые пути в другое место. Затем (МНОГОПОТОЧНОСТЬ!) в исходном месте он удаляется, и в новом естественном может иногда произойти доступ к уже удаленной памяти. Статический анализатор такое понять не в состоянии. После пары таких косяков я стал жестко переходить на shared+weak_ptr. помогло.
P.S. посмотрел прямо сейчас CLOC-ом, 320k sloc без 3rdparty, 40% — хедеры.
Да, наверное, Вы правы. У меня небольшой проект, около 150тысяч С++ кода, и когда я скачивал ваш анализатор год назад, он находил только предупреждения 3 уровня.
Интересно, прочел, задумался. Если OSI мертв уже два десятилетия, почему же когда я учился в вузе, нас дрюкали знать его наизусть? Специальность инженер-системотехник. И вроде как даже заставляли запоминать какие части TCP/IP стека в какой из уровней укладываются… Неужели это были ненужные знания? :D
Интересная идея. С учетом того, что у меня и так б/у 550D.
Качество фото — не профессиональное. И сравнивать цены на б/у мне кажется не очень корректным.
«И из них можно выбрать не больше двух»
И мне кажется, не получится выбрать сразу «качество изображения/управления» и «цена».
Иначе где профессиональные камеры за 10 тыщ рублей? (пусть и гигантские / или миниатюрные).
Ладно, виноват, выбрать все же можно, но увы, в очень ограниченных пределах.
По-моему, гораздо дешевле аудитору деньги отдать. Ведь нарушения с очень большой вероятностью будут. А если приедет налоговая, то будут штрафы. Так что выглядит байкой.
Я знаю, что стандартная. Я действовал в системе координат того преподавателя, который ставит гипотетические условия «а вот не все компиляторы поддерживают, что вы будете делать?»
Естественно в реальной практике о #ifndef M_PI не может быть речи.
Преподаватель: Да, этот код может нормально откомпилироваться. А может и нет. M_PI не определена в стандартах C или C++… (overquote)
Студент: да нет проблем!
Кстати, раз на то пошло — по результатам разных анализов стат.анализаторов (pvs, cppcheck, clang) — самая распространенная ошибка в моем проекте — неинициализированное поле (в том числе указатель). потенциальное *null лишь на втором месте.
Таких ошибок, как «эффект последней строки» или «эффект копипасты», почему-то ненаблюдалось. Обычно они очень быстро вылазят при первом же прогоне/тесте.
Ну еще довольно частые незначительные ошибки смешниваия int/size_t/uint32_t при доступе к контейнерам (при сериализации — нет).
Вот такая статистика =)
Да, ни один из стат анализаторов, к сожалению, не нашел ошибки, которая реально могла бы привести к порче/потере данных (потенциально, при каком-то дальнейшем изменении кода — да). Нет, не то что у нас прямо так идеально код пишут, я считаю, что то что было найдено- тоже полезно. Но больше с точки зрения прикладной диагностики принес нам valgrind (да, я читал ваши статьи про отличия динамического и статического анализа и понимаю что они мало где пересекаются).
Раз уж я рассказываю о своем опыте, опишу самый распространенный класс ошибок, найденный valgrind — выделяется память, сохраняется указатель, и потом передается через очень долгие и тернистые пути в другое место. Затем (МНОГОПОТОЧНОСТЬ!) в исходном месте он удаляется, и в новом естественном может иногда произойти доступ к уже удаленной памяти. Статический анализатор такое понять не в состоянии. После пары таких косяков я стал жестко переходить на shared+weak_ptr. помогло.
P.S. посмотрел прямо сейчас CLOC-ом, 320k sloc без 3rdparty, 40% — хедеры.
Качество фото — не профессиональное. И сравнивать цены на б/у мне кажется не очень корректным.
И мне кажется, не получится выбрать сразу «качество изображения/управления» и «цена».
Иначе где профессиональные камеры за 10 тыщ рублей? (пусть и гигантские / или миниатюрные).
Ладно, виноват, выбрать все же можно, но увы, в очень ограниченных пределах.
Естественно в реальной практике о #ifndef M_PI не может быть речи.
Студент: Как вам такой вариант?
Преподаватель: Да, этот код может нормально откомпилироваться. А может и нет. M_PI не определена в стандартах C или C++… (overquote)
Студент: да нет проблем!
(Ангарск — АГТА)
в Иркутском госе на ПМ преподают C++, C#, Python, Java.