Комментарии 33
case PrimaryID::SMPTEST432_1:
primary_id = gfx::ColorSpace::PrimaryID::SMPTEST432_1;
case PrimaryID::EBU_3213_E:
primary_id = gfx::ColorSpace::PrimaryID::INVALID;
break;
не выдает варнинга типа: value assigned to primary_id never used…?
(я очень редко влезаю в C/CPP, поэтому сам не знаю)
Comment 1.
Add a FALLTHROUGH macro and get base/ to build with -Wimplicit-fallthrough.
Also fix a few missing breaks found by the warning in gpu/.
primary_id = gfx::ColorSpace::PrimaryID::SMPTEST432_1;
значение присвоенное primary_id не используется — его сразу же переназначают.
Я это к тому, что, похоже, авторы Хромиума игнорируют варнинги компилятора.
PS: промахнулся с веткой :(
И я имел в виду, что раньше не использовался ключ, -Wimplicit-fallthrough (про него, кстати, говорится в статье). А теперь используется, что видно из общения в багтрекере разработчиков Chromium.
Двойные присваивания искать — дело совсем неблагодарное. Нужен умный инструмент, такой как PVS-Studio, чтобы снижать шум.
Эдак можно дойти до утверждения в духе «молотки сделаны неправильно — ими можно ударить по пальцу или убить кого-нибудь».
Именно по этой причине в мире «железных» вещей существуют правила, инструкции и техника безопасности, а при необходимости — те, кто следит за их исполнением, и которые наказывают нарушителей.
Мне кажется более логичным не ограничивать языки, а совершенствовать тех, кто их испольузет — прямо (обучение + опыт) или косвенно (статический + динамический анализы).
PS: Если бы у средств типа PVS-Studio была более либеральная ценовая политика, вероятно, это сильно бы улучшило качество кода и уменьшило количество ошибок для массы программистов. Большинство разработчиков, особенно в open source, не могут себе позволить платить $60/мес, в то время как действительно опытные разработчики в таких средствах не нуждаются вовсе.
действительно опытные разработчики в таких средствах не нуждаются вовсе.
Спорно. Даже самый опытный гуру может отвлечься/задуматься не о том/опечататься и т.д. и в результате получить в коде какую-то дичь. И далеко не всегда эта дичь вылезет сразу. Может оставаться в коде месяцами и годами.
"Никогда не посылай человека туда, куда можно послать пулю" © Джеймс Бонд.
Зачем тратить время гуру на то, что можно проверить автоматически?
В частности, логику проекта и его архитектуру проверить автоматически невозможно, то есть — отсутствие сообщений анализатора не говорит о том что ошибок нет, так что рано списывать гуру и заботится о его времени.
Вот в том-то и дело, что "рано списывать гуру". У него очень много дел, и не стоит загружать его ерундой.
Вообще сколько лет пишу на C и C++ — столько с тоской вспоминаю Паскаль каждый раз, как мне надо написать switch-case. 95% всех случаев "fallthrough" покрывались банальным перечислением констант через запятую или прописыванием диапазонов.
Ну и, опять же, если вернуться к аналогии с молотками — вариант с [[fallthrough]] не мешает вам ковырять молотком в носу, а лишь спрашивает вас — "вы действительно хотите это сделать"?.. По моему, хорошо. А вариант с оператором fallthrough вместо break — требует явно указывать "здесь ковырять в носу", зато избавляет от необходимости писать break каждый раз, как вам надо забить гвоздь.
В общем, подобные рассуждения не имеют практического смысла. Только наша команда нашла в Open Source проектах уже 13483 ошибки. Причём у нас никогда не было цели найти как можно больше ошибок и это просто побочны продукт процесса написания статей. Думаю, общее количество ошибок, которые исправлены благодаря нашему инструменту, исчисляется сотнями тысяч. Можно рассуждать теоретически о том, как сделать мир лучше и как сделать, чтобы программисты не ошибались. Но вот только всё равно они ошибаются и найденные нами ошибки это подтверждают. Поэтому использование PVS-Studio это практический шаг по улучшению качества и надёжности кода. А философию мы оставляем философам :)
Большинство разработчиков, особенно в open source, не могут себе позволить платить $60/мес, в то время как действительно опытные разработчики в таких средствах не нуждаются вовсе.Как раз всё наоборот. Многим разработчикам open source приложений в инструментах статического анализа не нуждаются. В маленьких проектах низкая плотность ошибок и нет старого унаследованного кода, который никто не знает. Ну или на крайний случай можно воспользоваться бесплатным вариантом PVS-Studio. Зато этот инструмент нужен и полезен профессиональным разработчикам и компания может позволить им его купить.
Руководствуясь приведённой логикой, не следует развивать Spelling & Grammar чекер в Microsoft Office, лучше учить детей в школе языку. Лучше? Лучше. И что дальше?
Я этого не говорил. Если применить вашу логику к данной аналогии — то нужно запретить Microsoft Office писать в документах слова с ошибками (ну или сохранять их) — а это уже зверство. Предупредить, направить — да, но последнее слово должно оставаться за автором.
Spelling / Grammar checker как раз нужны — ибо они помогают совершенствоваться.
Поэтому использование PVS-Studio это практический шаг по улучшению качества и надёжности кода.
Простите, но именно это я и сказал — если вы внимательно вчитаетесь :) Я просто против «внедрения» правил в сами языки (особенно если их нельзя обойти).
Зато этот инструмент нужен и полезен профессиональным разработчикам и компания может позволить им его купить.
Не все работают на компании, и не все зарабатывают кодом — но как раз именно они и «производят» больше всего ошибок.
Именно это и является большой проблемой, на мой взгляд — непрофессионалы пишут что-то полезное (и оно даже работает), но делают это «как умеют», т.е. с типичными проблемами, потом другие (уже включая профессионалов с небольшим опытом) копипастят их творения и множат проблемы. Иногда после разбора ответов на Stack Overflow волосы дыбом встают, но факт остается фактом — ответ который выполняет задачу принимается как «лучший», даже несмотря на наличие в нём потенциальных проблем, а дальше по спирали.
Но, поскольку эти самые непрофессионалы редко зарабатывают своим кодом, они вряд-ли подпишутся на такой тулз который стоит в общем-то, немало (даже весь комплект всего для разработчиков от JetBrains стоит дешевле, и он, кстати, включает в себя элементы статического анализа, а в Visual Studio это входит вообще даром — но не все могут им пользоваться).
Я просто против «внедрения» правил в сами языки (особенно если их нельзя обойти).
Языки программирования это одни сплошные правила, которые нельзя обойти. Вам всего лишь не нравится какое-то из них. Но даже если так, какое это имеет отношение к break и fallthrough? Это не ограничение, все возможности на месте, только теперь предотвращена очень распространенная ошибка.
К тому же, я уверен что молотками пользуется гораздо больше людей чем тех кто пользуется switch :)
Любой язык программирования и его возможности — это всего лишь инструмент.
Согласен, однако инструменты для одних и тех же целей могут быть с разной степенью безопасности. Циркулярная пила, например, может быть без защитного кожуха, а может быть и с ним.
Моя личная позиция по этому поводу: если можно сделать язык безопаснее на уровне базовых концепций — это должно быть сделано.
А где во втором примере ошибка? Или последовательность if без else для проверки одной и той же переменной — это тоже ошибка?
Как где? В случае GL_ALPHA8_EXT
будут последовательно выполнены *a=8; *a=16; *a=32;
, что не имеет смысла.
А где вы там if и else нашли?
Рекомендую определять их наравне с новыми средствами в духе этого C++17.
Оператор break и fallthrough