Wanted! Старые хиты Эрика Липперта

Если вы, вдруг не знали, то помимо всякой ерунды, публикуемой на этом блоге, я еще и занимаюсь переводом блога Эрика Липперта (Eric Lippert) Fabulous Adventures in Coding на русский язык. В русскоязычном варианте этот блог носит название Невероятные приключения в коде.

Занимаюсь я этим делом вот уже полтора года и не разу не пожалел потраченного времени. Я надеюсь, что чтение статей Эрика на русском языке доставляет хоть малую толику того удовольствия, которое я получаю при переводе!

Но сегодня я не об этом. Точнее не совсем об этом. Мы начали публиковать переводы, датированные апрелем 2009-го года, но, как это ни удивительно, до этого Эрик писал не менее часто и не менее интересно. Посему я предлагаю вернуться к его старым хитам и восстановить, так сказать, справедливость и перевести на русский язык и их.

Неявно типизированные поля в C#

Сегодня на кывте был задан очередной весьма интересный вопрос о том, почему в языке C# существуют неявно типизированные локальные переменные (implicitely-typed local variables) a.k.a. var, но нет неявно типизированных полей?

На самом деле, такое положение дел вовсе не случайно; так что давайте рассмотрим несколько причин, почему компилятор ведет себя именно так, а не иначе.

Во-первых, возможность использовать var, для объявления неявно типизированных локальных переменных, никогда не была самостоятельной возможностью. При разработке языка C# никто не ставил перед собой цели создать полностью неявно типизированный язык программирования, типа F#; неявная типизация была лишь одной составляющей (пусть и немаловажной) более общей концепции, известной сегодня под аббревиатурой LINQ.

О книге “MS Visual C++ 2010 в среде .NET. Библиотека программиста”

Если посмотреть на мои обзоры книг (*), то может возникнуть подозрение в предвзятости, поскольку отзывы либо положительные, либо восторженные. Объясняется эта ситуация довольно просто: прежде чем браться за чтение книги разумно совершить «разведку боем» и выяснить, насколько чтение той или иной книги полезно и актуально. Если отзывы на книгу хорошие, автор внушает доверие, а тема интересна, то есть все шансы на то, что и вы не пожалеете о потерянном времени. Если же отзывы сугубо отрицательные и за версту тянет стилем изложения «Для чайников» в самом плохом смысле этого слова, то и время на такую книгу тратить не стоит.

Сегодня же будет исключение из этого правила, связанное, в первую очередь с тем, что это не совсем рецензия, а результаты упомянутой выше «разведки боем», однако ее было более чем достаточно, чтобы сложилось вполне конкретное впечатление об этом творении.

Effective Concurrency от Герба Саттера

Герб Саттер, если вдруг кто не знает, это гуру С++ и многопоточности, автор нескольких весьма популярных книг и сотни известных статей, главный дизайнер языка C++/CLI и всяких там многопоточных расширений, в общем, крут парень, ничего не скажешь.

Но именно в данном случае интересно не это. Сегодня я отправил Гербу мыло с просьбой разрешить перевод и публикацию у себя в блоге его серии статей Effective Concurrency, и получил от него ответ через 40 (!) минут. То что ответ был отрицательным, это уже второе, но сам факт, что такие люди отвечают столь оперативно не может не радовать.

К сожалению, права на статьи серии Effective Concurrency принадлежат издательству Addison-Wesley, поскольку планируется выпуск одноименной книги, и эти ребята не разрешают никаких других публикаций, как минимум до выхода англоязычной книги в свет. А состоится этот выход в свет, по словам Герба, не раньше следующего года, ибо дел сейчас у него по горло (что не удивительно в свете событий, связанных с финальной стадией принятия нового стандарта С++).

Так что у нас, как всегда, две новости: одна хорошая, другая – не очень. Хорошая новость заключается в том, что Герб отличный парень и у нас скоро будет его новая книга, ну а плохая – что это “скоро” наступит не раньше следующего года.

Дополнительные ссылки

• Ко всем статьям из серии Effective Concurrency можно достучаться через один из постов блога Герба по этой теме, например, отсюда: Effective Concurrency: Know When to Use an Active Object Instead of a Mutex
• Еще рекомендую посмотреть записи с Гербом на Channel9:
• Conversation with Herb Sutter: Perspectives on Modern C++(0x/11) – веселое интервью, в основном посвященное вопросам процесса стандартизации и новым фичам С++.
• E2E: Herb Sutter and Erik Meijer - Perspectives on C++ – серия с Эриком Мейером Expert To Expert, мне вообще кажется одной из самых интересных; так что, рекомендую
• Остальные записи с Гербом на Channel9

Гарантии безопасности исключений

Ошибки в обработке ошибок являются наиболее распространенным источником ошибок
Бредня, пришедшая в голову при написании этой статьи

Основные баталии по поводу того, что лучше использовать при программировании на C# – исключения или коды возврата для обработки, ушли в далекое прошлое (*), но до сих пор не утихают баталии другого рода: да, хорошо, мы остановились на обработке исключений, но как же нам их обрабатывать «правильно»?

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

Существует множество «за» и «против» такого способа перехвата и обработки исключений, но сегодня я хочу рассмотреть несколько другую тему. А именно тему обеспечения согласованного состояния приложения в свете возникновения исключения – три уровня безопасности исключений.

О синглтонах и статических конструкторах

Изначально автор хотел назвать эту статью следующим образом: «О синглтонах, статических конструкторах и инициализаторах статических полей, о флаге beforeFieldInit и о его влиянии на deadlock-и статических конструкторов при старте сервисов релизных билдов в .Net Framework 3.5», однако в связи с тем, что многострочные названия по неведомой автору причине так и не прижились в современном компьютерном сообществе, он (автор) решил сократить это название, чудовищным образом исказив его исходный смысл.

-------------------------

Любая реализация паттерна Синглтон в общем случае преследует две цели: во-первых, реализация должна быть потокобезопасной, чтобы предотвратить создание более одного экземпляра в многопоточном мире .Net; а во-вторых, эта реализация должна быть «отложенной» (lazy), чтобы не создавать экземпляр (потенциально) дорого объекта раньше времени или в тех случаях, когда он вообще может не понадобиться. Но поскольку основное внимание при прочтении любой статьи про реализацию Синглтона отводится многопоточности, то на «ленивость» зачастую не хватает ни времени не желания.