“Не стоит следовать некоторой идиоме только потому, что так делают все или так где-то написано”

Мысли автора статьи во время чтения и рефакторинга чужого кода

Ни для кого не будет секретом, что платформа .NET поддерживает автоматическое управление памятью. Это значит, что если вы создадите объект с помощью ключевого слова new, то вам не нужно будет самостоятельно заботиться о его освобождении. Сборщик мусора определит «достижимость» объекта, и если на объект не осталось корневых ссылок, то он будет освобожден. Однако, как только речь заходит о ресурсах, таких как сокет, буфер неуправляемой памяти, дескриптор операционной системы и т.д., то сборщик мусора, по большому счету, умывает руки и весь головняк по работе с такими ресурсами ложится на плечи разработчика.

А как же финализаторы? – спросите вы. Ну, да, есть такое дело, финализаторы действительно предназначены для освобождения ресурсов, но проблема в том, что время их вызова не детерминировано, а это значит, что никто не знает, когда они будут вызваны и будут ли вызваны вообще. Да и порядок вызова финализаторов не определен, поэтому при вызове финализатора некоторые «части» вашего объекта уже могут быть «разрушены», поскольку их финализаторы уже были вызваны. В общем, финализаторы – они-то есть, но это скорее «страховочный трос», а не нормальное средство управления ресурсами.

На прошедшей недавно конференции Build кроме уже широко освещенной и обсужденной презентации Windows 8, Metro UI и WinRT было еще немало интересного. В том числе, Дон Сайм и его команда представили developer preview новой, третьей по счету, версии языка программирования F#, который является частью developer preview Visual Studio 11 (и, кстати, уже может быть опробована вами по ссылке).

Когда-то во время учебы в университете, преподаватель, проверяя лабораторную работу по C++, вдруг неожиданно для меня задал вопрос: “А зачем вам здесь #include “%имя_библиотеки%”? Вы можете пояснить, для каких частей кода нужна каждая директива include?” Та директива, что «бросилась ему в глаза», была добавлена при попытке использовать какой-то класс. Класс, видимо, не прижился в лабораторной и его использование было благополучно удалено, а include остался…

Программируя в С#, с использованием Visual Studio, мы так же сталкиваемся с неиспользуемыми директивами using. Но Visual Studio может помочь справиться с проблемой, достаточно для .cs файла вызвать команду “Remove Unused Usings”. Правда есть еще одно место, которое так же не мешало бы время от времени чистить. Это ссылки (References) проекта. Как ни печально, но для C# проекта такой команды нет. В MS Connect даже баг создали по этому поводу. А вот для VB.NET проектов такая функция есть (найти её можно в свойствах проекта), но по злой иронии судьбы для VB.NET проектов нет команды для удаления неиспользуемых Imports (usings в C#) :)

Подогреваемые жаждой сделать полезное коллегам, независимые разработчики решили написать небольшие расширения для Visual Studio. А тут еще и Extension Manager из Visual Studio 2010 так упростил процесс распространения расширений. Пример таких расширений можно найти здесь и здесь. Невозможно судить об алгоритмах, используемых в этих расширениях. Хотя не буду скрывать, что после того как первое расширение бессовестно удалило из проекта приличную часть реально нужных для компиляции сборок, мы все таки посмотрели его рефлектором… Разбираться со вторым уже не стали. В общем-то, проблема одинакова, а ключевое словосочетание можно найти в пред-предыдущем предложении: нужных для компиляции.

+ развернуть текст   сохранённая копия

Тэги: .net, 4.5, build

.NET / Простой пример получения негатива изображения в .NET Версия 2.0

   2011-09-21 16:46:09
Сегодня утром я написал топик, который был встречен серьезной критикой. Суть критики заключалась в ...
+ развернуть текст   сохранённая копия

Тэги: .net, изображение, работа