Как стать автором
Обновить
52
0
Павел Еремеев @Paull

Технический директор

Отправить сообщение
Т.е. если я реализую свой класс, наследуя его от CriticalFinalizerObject и в нём реализую собственный финализатор, то он будет застрахован от всех проблем, описанных здесь? При этом я не говорю сейчас про использование стандартных классов-наследников CriticalFinalizerObject наподобие того-же SafeHandle, тема статьи именно реализация собственных финализаторов.
Статья дает рекомендации на базе заведомо неверной информации.

Как я понимаю, вы про это:
Непосредственно их использовать скорее вредно, чем бесполезно, вот только причина совсем другая:
у наследников CriticalFinalizerObject гарантии выполнения кода завершения лучше, чем у финализатора.

Статья должна была сказать, что использовать финализаторы не нужно, потому что есть CriticalFinalizerObject, и нужно всегда использовать его? А разве CriticalFinalizerObject лишён всех минусов, которые перечислены в статье? Может быть статью стоило назвать тогда «Почему не стоит использовать CriticalFinalizerObject»?
Финализаторы нужны только для аварийной очистки системных ресурсов, дабы утечки в вашем проекте не поставили в неудобную позу всю машину — об этом ни слова.

Финализаторы не нужны по совсем другой причине — для аварийной очистки есть более надежное место.


Не очень понятно, для чего по вашему мнению всё-таки подходит использование финализаторов.

Непосредственно их использовать скорее вредно, чем бесполезно


Как по вашему это противоречит содержанию статьи?
На самом деле, для C# мы используем ещё FxCop )
Спасибо за отзыв! Похоже на ложное срабатывание, мы постараемся поправить.
Отпишите, пожалуйста, баг на support@viva64.com, мы попробуем разобраться.
Проекты добавлены в sln файле через относительные пути? В первых версиях PVS-Studio C# была проблема с тем, что не проверялись проекты, заданные через относительные пути. Попробуйте проверить в последней версии, доступной на files.viva64.com/beta/PVS-Studio_setup.exe.
Возможно, вы не сохранили файл solution'а? PVS-Studio читает этот файл независимо от студии.

Для отключения предупреждений — меню PVS-Studio|Options...|Detectable Errors (C#).
В появляющемся окошке (при проверке одного проекта) указывается какое-то количество файлов?

Может быть файлы в проекты включены не как цели для компиляции (можно посмотреть в свойствах файла)? Также отдельные участки кода не будут проверены, если они заключены в define'ы, не определённые для проверяемого проекта.

Если возможно, пришлите пожалуйста csproj файл на support@viva64.com, мы попробуем разобраться.
Что пишется, когда пытаетесь проверить один файл? А если проверить один проект (через контекстное меню в Solution Explorer)? Solution включает обычные csproj проекты?

Также можно попробовать проверить solution напрямую из командной строки с помощью PVS-Studio_Cs.exe, возможно проблема на стороне Visual Studio плагина.
Проверьте, пожалуйста, какую платформу\конфигурацию вы проверяете. Если для какой-либо конфигурации сборка проекта отключена, то PVS-Studio не будет проверять такой проект.
В статье имелось в виду, что мы мигрируем для C# самые простые General Analysis проверки C++ версии PVS-Studio, у нас нет в планах дублировать проверки каких-либо других анализаторов. Безусловно, неизбежно пересечение наших диагностик и диагностик других анализаторов, но это не означает, что они идентичны.
Пришлите пожалуйста тестовый проект, на котором повторяется ошибка на support@viva64.com, мы посмотрим, что можно сделать.
Да, действительно есть такой нюанс, мы посмотрим, что можно с этим сделать. Пока что вы можете прислать просто plog, там все Fail будут видны. Его можно получить через команду меню PVS-Studio|Open/Save|Save Analysis Report As
Вы также можете попробовать command line версию. Для просмотра отчёта можно использовать утилиту Standalone.
Для интеграции анализа C# кода в Continuous Integration / Build Automation и т.п. системы, вы можете использовать Command line анализатор напрямую. Подробная документация доступна тут.
В идеале — прислать маленький примерчик, на котором повторяется падение. Но мы будем благодарны, если вы пришлёте хотя бы стек падения\plog, если такой возможности нет.
Ориентируясь на LLVM, раз в 5 больше. Но мы и так уже решили добавить данный проект в регулярные проверки, посмотрим, что из этого получится )
Прошу прощения, в статье опечатка была ) Имелась в виду Miranda IM всё-таки )
У Miranda NG за этот же период — порядка 4000 ревизий, не так уж и много для наших целей, к сожалению.

Информация

В рейтинге
Не участвует
Откуда
Тула, Тульская обл., Россия
Работает в
Дата рождения
Зарегистрирован
Активность