Здравствуйте, я — программист, но не пишу на плюсах профессионально, предпочитая для зарабатывания денег языки более «пластмассовые», навроде java и python, где цена ошибки не так высока, дебаг прост, а стектрейсы из логов и сообщения об ошибках практически всегда имеют смысл, а не представляют из себя «ошибка по адресу-хекс-код, память cannot be read», тем не менее, иногда пописываю на плюсах «для души», для общего развития так сказать. И вот вопрос у меня есть, есть отличный компилятор GCC, есть Intel C++ Compiler, есть MSVC++ (или как он там называется правильно), и в каждом из них есть некая подсистема, которая напоминает модуль статического анализа. Я говорю о предупреждениях: к примеру, отсутствующий возврат из не-void функции в GCC будет обнаружен при включенном -Werror=return-type. Повторюсь, я не специалист по плюсам, но пройдемся по статье:
V533 (инкремент «не той» переменной в for-цикле) — найти for-циклы в AST, проверить на пересечение множества перменных из условия и действия. Я из головы пишу сейчас — естественно, поразмыслив, можно усложнить проверку, например оценить характер изменения переменных и «направлений» условий, то есть, скажем, заставить i++ требовать условия i < X, а для i > Y — выбрасывать ошибку, однако, это не rocket-science. Да, работа, да, возможно, сложная, но не матан.
V581 — вообще смешно — сравнить на равество условия последовательных ифов. Вы ведь тоже не можете оценить значение всех сайд-эффектов? Думается мне, это в статике в плюсах вообще невозможно в общем случае, это под силу только динамическим анализаторам, ну может только в каких-то частных случаях если — статически.
V517 — то же самое.
V524 — то же самое. Тело функции, конечно, как правило, длиннее условия, но когда оперируешь AST, а не строками текста, отступы, форматирование и прочее — не играют роли, препроцессор уже прошел, предоптимизация выкинула очевидный «мертвый» код, все < и > «повернуты» в одну сторону и т.д. — красота!
V591 — как я уже говорил, в GCC это работает из коробки как минимум.
V575 — …
Вообще и так длинно получилось, суть, я думаю, и так ясна.
Конечно, есть и сложные для обнаружения проблемы, но в статье не описана ни одна из них, хотя, быть может, я и недооцениваю. Хм, скажем так, по сравнению с логикой самого GCC в статье я не нашел ни одной хоть сколько бы то ни было алгоритмически сложной в поиске ошибки.
И вот, собственно, вопрос, почему ребята, которые пишут GCC не добавили все это внутрь их компилятора? Или майки в свой? Ну ладно, первые — волонтеры, вторые — бюрократы, но как насчет интеловцев? Они-то знают толк? Или нет?
Я вижу здесь два варианта:
1. Добавление всех этих проверок в компилятор ни сколько не увеличит количество проблем и качество работы программ, написанных на плюсах. Улучшит качество кода? Да! Но очень плохо написанный код может работать очень хорошо, а в очень красивом, как дипломная работа студента, коде — быть скрытая ошибка. Вы много продуктов проверяли и многие из них работают хорошо. Относительно — хорошо. В этом мире все относительно. По крайней мере я не встречал идеального кода еще в своей жизни. И идеальных программ тоже. Я не часто лазаю по чужому коду, но вот хотел в tmux добавить true color когда-то, но так и не осилил, там просто ад внутри, копипаста, какие-то хаки под разные платформы, наслоения функциональности, и это — чистый си. А программка-то работает как часы, да и true color к ней кто-то прикрутил и без моего участия.
Чтобы процесс детачнулся под линуксом достаточно передать close_fds = True в аргументах к Popen(), хотя под виндой может потребоваться поиграть с флагом DETACHED_PROCESS (http://stackoverflow.com/questions/13592219/launch-a-totally-independent-process-from-python).
Добавлю, что человек, который закоммитит файл some_file_which_ends_with_py, game.spy, например, будет неприятно удивлен.
Не в обиду никому, но приоритезация не ускорит I/O, а только переместит проблему в другое место, где ее будет не так сильно заметно. Почему бы не приобрести SSD (если бюджет скромный) или не замутить RAID (если деньги позволяют)?
Лямбды в питоне, по большему счету — синтаксический сахар над функцией из одного действия. Если действий несколько — нет другого выхода, кроме как использовать функции. Только обычно незачем делать лямбду, в который вызывается функция, можно передать имя функции туда, куда передаете лямбду. Обертки лямбды функцией не избежать только тогда, когда сигнатуры не совпадают, но, насколько я понял, это не ваш случай.
Говорят, что к лету-осени этого года допилят amdgpu (опенсорсный драйвер), а потом сделают fglrx проприетарной надстройкой над ним. В итоге, у них будет значительная часть общего кода, примерно одинаковая производительность, плюс/минус всякие проприетарные технологии/расширения. На мой взгляд, ситуация похожа на историю с KDE 5 — чтобы сделать что-то новое, пришлось сломать старое. в AMD, похоже, не слишком много людей работает над этим, к сожалению.
Немного информации (из первых рук — от разработчиков AMD) здесь:
V533 (инкремент «не той» переменной в for-цикле) — найти for-циклы в AST, проверить на пересечение множества перменных из условия и действия. Я из головы пишу сейчас — естественно, поразмыслив, можно усложнить проверку, например оценить характер изменения переменных и «направлений» условий, то есть, скажем, заставить i++ требовать условия i < X, а для i > Y — выбрасывать ошибку, однако, это не rocket-science. Да, работа, да, возможно, сложная, но не матан.
V581 — вообще смешно — сравнить на равество условия последовательных ифов. Вы ведь тоже не можете оценить значение всех сайд-эффектов? Думается мне, это в статике в плюсах вообще невозможно в общем случае, это под силу только динамическим анализаторам, ну может только в каких-то частных случаях если — статически.
V517 — то же самое.
V524 — то же самое. Тело функции, конечно, как правило, длиннее условия, но когда оперируешь AST, а не строками текста, отступы, форматирование и прочее — не играют роли, препроцессор уже прошел, предоптимизация выкинула очевидный «мертвый» код, все < и > «повернуты» в одну сторону и т.д. — красота!
V591 — как я уже говорил, в GCC это работает из коробки как минимум.
V575 — …
Вообще и так длинно получилось, суть, я думаю, и так ясна.
Конечно, есть и сложные для обнаружения проблемы, но в статье не описана ни одна из них, хотя, быть может, я и недооцениваю. Хм, скажем так, по сравнению с логикой самого GCC в статье я не нашел ни одной хоть сколько бы то ни было алгоритмически сложной в поиске ошибки.
И вот, собственно, вопрос, почему ребята, которые пишут GCC не добавили все это внутрь их компилятора? Или майки в свой? Ну ладно, первые — волонтеры, вторые — бюрократы, но как насчет интеловцев? Они-то знают толк? Или нет?
Я вижу здесь два варианта:
1. Добавление всех этих проверок в компилятор ни сколько не увеличит количество проблем и качество работы программ, написанных на плюсах. Улучшит качество кода? Да! Но очень плохо написанный код может работать очень хорошо, а в очень красивом, как дипломная работа студента, коде — быть скрытая ошибка. Вы много продуктов проверяли и многие из них работают хорошо. Относительно — хорошо. В этом мире все относительно. По крайней мере я не встречал идеального кода еще в своей жизни. И идеальных программ тоже. Я не часто лазаю по чужому коду, но вот хотел в tmux добавить true color когда-то, но так и не осилил, там просто ад внутри, копипаста, какие-то хаки под разные платформы, наслоения функциональности, и это — чистый си. А программка-то работает как часы, да и true color к ней кто-то прикрутил и без моего участия.
2. Я что-то не понимаю в этом мире :)
Добавлю, что человек, который закоммитит файл some_file_which_ends_with_py, game.spy, например, будет неприятно удивлен.
Немного информации (из первых рук — от разработчиков AMD) здесь:
www.phoronix.com/forums/forum/phoronix/general-discussion/857070-ubuntu-is-deprecating-fglrx-catalyst-in-16-04-lts