Pull to refresh
52
0
Павел Еремеев @Paull

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

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

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

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

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


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

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


Как по вашему это противоречит содержанию статьи?
Спасибо за отзыв! Похоже на ложное срабатывание, мы постараемся поправить.
Отпишите, пожалуйста, баг на 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 ревизий, не так уж и много для наших целей, к сожалению.

Information

Rating
Does not participate
Location
Тула, Тульская обл., Россия
Works in
Date of birth
Registered
Activity