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

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

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

Здравствуйте, Великие и Ужасные хабражители!
Как я недавно узнал, не так много народу знает о том, как работает сборщик мусора. Хотя я понимаю, что 99% разработчиков это не особо нужно, но я хотел бы, чтобы все, кто разрабатывают приложения на .NET, знали принцип его работы. В этой статье я постараюсь вкратце рассказать, как собственно работает сборщик мусора.

Базовые сведения о времени жизни объекта

Как известно, при инициализации объекта в памяти выделяет нужное под объект место. Использование ключевого слова new приводит к добавление объекта класса в так называемую управляемую кучу, а назад возвращается ссылка на объект.
При создании приложений на C# можно смело полагать, что исполняющая среда .NET будет сама заботиться об управляющей куче без непосредственного вмешательства со стороны программиста. На самом деле "золотое правило" по управлению памятью звучит так:

Размещайте объект в управляющей куче с помощью ключевого слова new и забывайте об этом.

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

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

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

История 1

Собственно, началось все с того, что пришел баг о том что при некоторых операциях приложение вылетает. Это бывает часто. Баг не захотел воспроизводиться в Debug-версии. Это порой бывает. Поскольку в приложении часть библиотек была написано на C++, то первой мыслью было что-то вроде «где-то забыли переменную проинициализировать или что-то в этом духе». Но на деле суть бага крылась в управляемом коде, хотя без неуправляемого тоже не обошлось.

Всем привет! Помните, когда-то давным давно была хорошая серия статей? Так вот я хочу ее продолжить. Однако на этот раз я не буду рассматривать огромное множество библиотек, которые решают повсеместно-возникающие проблемы, а рассмотрю всего лишь одну, но способную решить огромную кипу проблем. Мне кажется каждый из вас когда-то писал строчки вида:

void SomeMethod(IEmployee lazyguy)
{
    if(lazyguy == null) throw new ArgumentException(“lazyguy”);
    // Do something with lazy guy. Fire him, for example.
}

Кто-то пытался превратить это в:

void SomeMethod(IEmployee lazyguy)
{
    UniversalValidator.CheckNotNull(lazyguy);
    // Meet with him and talk about motivations
}

Кто-то превращал это во что-то похожее. Однако у всех, я могу поспорить, оставался осадок что что-то тут не так. Красивее было бы как-то по другому. А что в итоге? Огромное количество велосипедов с квадратными колесами! Как сделать по-другому?

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

Вступление

В этой статье я постараюсь максимально полно и пошагово рассказать, как связать MATLAB с С#.NET и сделать приложение с интерфейсом на примере построения 3D-плоскости.

Зачем это нужно?

Очень часто перед программистом встает задача вычисления сложной математики. MATLAB в свою очередь является отличным средством для решения, но слаб в создании полноценного пользовательского приложения (можно воспользоваться инструментами GUI MATLAB'a, но это меня не устроило).

Общее представление о том, что такое WPF Layout System, можно получить из msdn (1, 2). Там написано, что элементы управления образуют Visual-дерево, что каждый из элементов управления имеет свой определенный прямоугольник, в рамках которого он отрисовывается, что определение этих прямоугольников возлагается на Layout System и выполняется в 2 этапа (measure и arrange) и что WPF — это retained mode graphic system, в отличие от обычных Immediate и в чем преимущества такого подхода.

Однако при чтении msdn возникает ряд вопросов, на которые в документации ответов нет, и можно только догадываться о том, что происходит. Например — что произойдет, если какой-либо дочерний контрол в measure-стадии запросит для себя размер, превышающий переданный ему availableSize? Или — как при необходимости реализовать методы MeasureOverride и ArrangeOverride правильно, чтобы написанный код не противоречил принятым соглашениям о том, как должны выполняться этапы Measure и Arrange ? Влияет ли результат, полученный на этапе Measure, на этап Arrange и отрисовку, или же на отрисовку влияет только вызов Arrange, а Measure — чисто информационный этап?

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

Есть некоторые категории знаний, которые профессиональный разработчик познает в процессе своей работы, не прилагая к этому особенных дополнительных усилий. Вот, например, мало кто из нас читал замечательную книгу по регулярным выражениям Джеффри Фирддла, чтобы познакомиться с одноименной темой. Безусловно, есть масса людей, для которых «регвыры» стали смыслом жизни и без подобных фундаментальных знаний никак не обойтись. Но в большинстве случаев пары мелких статей и справки в соответствующем разделе документации будет достаточно для более или менее комфортной работы с регулярными выражениями (если такое понятие, как «комфортная работа» с регулярными выражениями вообще существуетJ).

Аналогичным образом мы обычно относимся и к изучению юнит тестирования. Ведь юнит-тесты – это же не rocket science; для их изучения не требуется многолетняя подготовка и множество бессонных ночей проведенных за изучением толстенных «талмудов» от гуру юнит-тестирования. Концепцию автоматизированного тестирования кода можно объяснить за 10 минут, а познакомившись с одним из тестовых фреймворков семейства xUnit (еще 15 минут), вы сможете работать с любым другим фреймворком практически сразу же. Затем нужно будет потратить еще 20 минут на изучение какого-нибудь изоляционного фреймворка, типа Rhino Mocks, и, вуаля, у нас есть еще один профессионал в области юнит-тестов.

От переводчика:
Не так давно мой менее опытный коллега спросил меня о том, для чего используется yield return в C#. Я не очень часто пишу свои итераторы, поэтому, отвечая ему, я сомневался в своих словах. Справившись в MSDN, я укрепился в сказанном, но у меня возник вопрос: “А во что же всё таки компилируется эта инструкция?” К тому моменту, я уже был знаком с переводимой статьёй, однако всё, что в ней сказано, давно “выветрилось”. Статья старая, но мне думается, что она может быть полезна для определённой группы разработчиков, привыкшей читать русскоязычные статьи и документы.

Ссылка на продолжение: реализация итераторов в C# (часть 2)

Реализация итераторов в C# (часть 1).

Теперь, когда вы имеете в своём багаже общее представление о том, что стоит за итераторами, вы уже можете ответить на некоторые вопросы их использования. Вот сценарий, основанный на реальных событиях:

Пол года проработав в компании, которая занимается программированием на MQL под Meta Trader столкнулся с таким заказом: клиенту нужно что бы программа была написана на C# или VB.Net.

Задача была в том, что бы написать программу на C# и dll на том же языке, которая связывает приложение с торговым советником на MQL. С одной стороны мне это на руку, так как C# изучаю больше года, с другой — стало непонятно, а как же это делается и вообще возможно ли это?

Контекст

С данным вопросом встретился при работе над одним из проектов, в котором очень много настроек. В виду того что добавление новых настроек происходило по ходу разработки то выявилась необходимость сделать класс к которому можно обратится из любого модуля программы. Для этого конечно был использован статический класс, а назвали мы его AppSettings. Конечно можно было бы использовать Properties.Settings… Не буду вдаваться в детали, но этот вариант не подходил.

Суть проблемы

Из за того что класс является статическим обычная сериализация не работает. Давайте проверим. Допустим, у нас есть простой статический класс:

public static class TestStatic
{
	// Fields...
	private static int _Counter;
	public static int Counter
	{
		get { return _Counter; }
		set
		{
		        _Counter = value;
		}
	}       
}

В общем если класс не был бы статическим, можно было бы использовать System.Xml.Serialization.XmlSerializer. Это не наш случай — класс у нас статический и в этом случае, по тому, что XmlSerializer.Serialize метод требует экземпляр класса, а не тип класса, то компилятор выдаст 'Test1.TestStatic' is a 'type' but is used like a 'variable'.

В недавно вышедшей Visual Studio 11 Beta встроена новая и главная фишка будущего C# 5 — асинхронное программирование с помощью async/await. Про нее уже написано достаточно много статей в том, числе на хабре — например, эта серия статей. Однако, я для себя так и не понял в чем суть нового синтаксиса, пока сам не попробовал его в деле. Данная статья — попытка самому структурировать и до конца разобраться с этим достаточно интересным инструментом и поделиться результатами с сообществом, рассказав про него немного иначе. Итак, поехали…

Рассмотрим некоторые части .Net Framework'a, выглядящие тривиальными, но вполне способными сделать ваш код более простым как в написании, так и в сопровождении.


Пишущие на .NET (а если вы этого не делаете, то зря читаете этот пост) наверняка время от времени используют для своих нужд структуру DateTime. Эта структура удобна для хранения дат, времени или даты/времени, относящихся к локальной временной зоне (или же к UTC).


Однако, бывают случаи, когда вам необходимо сохранить время в виде смещения, а не конвертировать его в локальное время. И вот здесь вам на помощь придёт структура, впервые появившаяся в .NET 3.5 — DateTimeOffset.

Доброго времени суток!



Недавно в сети Tuts+ Premium был анонсирован новый курс под названием "30 Days to Learn C#". Его целью является обучение новоиспечённых программистов языку C#, разработанному компанией Microsoft, а также работе с платформой .NET. Этот курс, разумеется, не сделает из вас настоящего профессионала, а всего-лишь произведёт первое знакомство с языком и платформой в целом. Курс охватывает следующие темы:

Замечания:
1. В предыдущей заметке "time zone" я перевёл как «временнАя зона», поскольку речь шла о часовых поясах США, имеющих специфическое название. В данном случае корректнее использовать "часовой пояс". Здесь используется более корректный перевод.

2. Небольшая врезка из Википедии даст вам понимание что такое UTC и чем оно отличается от GMT —

Всеми́рное координи́рованное вре́мя (UTC) — стандарт, по которому общество регулирует часы и время. Отличается на целое количество секунд от атомного времени и на дробное количество секунд от всемирного времени UT1.

UTC было введено вместо устаревшего среднего времени по Гринвичу (GMT). Новая шкала времени UTC была введена, поскольку шкала GMT является неравномерной шкалой и связана с суточным вращением Земли. Шкала UTC основана на равномерной шкале атомного времени (TAI) и является более удобной для гражданского использования.

Часовые пояса вокруг земного шара выражаются как положительное и отрицательное смещение от UTC.

Следует помнить, что время по UTC не переводится ни зимой, ни летом. Поэтому для тех мест, где есть переход на летнее время, меняется смещение относительно UTC.


Теперь продолжим разбираться со структурами, обслуживающими такие сущности, как дата и время.

Через некоторое время после публикации твита о Noda Time, меня начали спрашивать, какой смысл в использовании Noda Time — люди верили, что поддержка дат и времени в .NET вполне хороша. Я конечно не видел их код, но подозреваю, что практически любая кодовая база, имеющая дело с датами, станет яснее, если будет использовать Noda Time, а также, вполне возможно, станет более корректной благодаря подходу, с помощью которого Noda Time заставляет вас принимать некоторые, не очевидные в .NET, решения. В этой заметке мы обсудим недостатки .NET API, обеспечивающего работу с датами и временем. Моё отношение к этой теме выглядит несколько предвзятым, но я надеюсь, что эта заметка не выглядит неуважительно по отношению к команде, работающей над BCL (Base Class Library — прим. переводчика) — поскольку, кроме всего прочего, они работают в условиях, заставляющих их принимать во внимание взаимодействие с COM и т.п.

Как-то мне понадобилось проверить, является ли XML-имя правильным. Что может быть проще? Смотрим стандарт, где четко описано, какими символами может имя начинатся, а какими — продолжаться, все просто и понятно:

[4] NameStartChar ::= ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]
[4a] NameChar ::= NameStartChar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]
[5] Name ::= NameStartChar (NameChar)*


Практически готовое регулярное выражение, легкая обработка напильником Ctrl+H…

    public const string NameStartCharPattern = @"\:|[A-Z]|_|[a-z]|[\u00C0-\u00D6]|[\u00D8-\u00F6]|[\u00F8-\u02FF]|[\u0370-\u037D]|[\u037F-\u1FFF]|[\u200C-\u200D]|[\u2070-\u218F]|[\u2C00-\u2FEF]|[\u3001-\uD7FF]|[\uF900-\uFDCF]|[\uFDF0-\uFFFD]|[\u10000-\uEFFFF]";
    public const string NameCharPattern = NameStartCharPattern + @"|-|\.|[0-9]|\u00B7|[\u0300-\u036F]|[\u203F-\u2040]";
    public const string NamePattern = @"(?:" + NameStartCharPattern + @")(?:" + NameCharPattern + @")*";
* This source code was highlighted with Source Code Highlighter.

Пишем тест…

Assert.That(Regex.Match("4a", Patterns.NamePattern), Is.False);
* This source code was highlighted with Source Code Highlighter.

Чисто, просто, понятно… Упал!

Большинство источников по использованию атрибутов [1, 2] рассказывают, что они есть, «обеспечивают эффективный способ связывания метаданных или декларативной информации с кодом», могут быть получены при помощи отражений [3]. В рамках данной статьи, я попробую показать прикладной пример применения атрибутов: проверка заполненности обязательных полей на форме добавления/редактирования нового бизнес-объекта.
Перед тем, как вы нажмете подробнее, несколько предупреждений:
1. Если вы уже работали с атрибутами, то, возможно, вам будет неинтересно.
2. При написании демонстрационного примера были допущены существенные упрощения (например, отказ от MVVM), с целью облегчения восприятия материала про атрибуты.

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

Пример использования

HotKeysManager manager = new HotKeysManager();
manager.AddHotKey(new HotKeyCombination(() => { MessageBox.Show("Привет, Хабр!"); }) { Keys.LControlKey, Keys.H });

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

manager.AddHotKey(new HotKeyCombination(HookManager.CurrentDownedKeys.ToArray(), () => { MessageBox.Show("Привет, Хабр!"); }));

Теперь при нажатии комбинации LeftCtrl+H (или H+LeftControl), мы увидим приветственное сообщение.