Определение символа разделителя десятичного числа C#

Для этих целей служит

string separator = System.Globalization.CultureInfo.CurrentCulture
.NumberFormat.NumberDecimalSeparator;

Этим мы получим разделитель для текущей культуры, также оттуда можно получить еще много чего полезного.

http://msdn.microsoft.com/ru-ru/library/system.globalization.numberformatinfo.numberdecimalseparator.aspx

regular expressions (regex) - справочник

[abc]
Один символ: a, b или c
A single character of: a, b or c
[^abc] Любой символ, за исключением: a, b или c Any single character except: a, b or c
[a-z] Любой одиночный символ из диапазона a-z Any single character in the range a-z
[a-zA-Z] Любой символ в диапазоне a-z или A-Z Any single character in the range a-z or A-Z
^ Начало строки Start of string
$ Конец строки End of string
. Любой символ Any single character
\s Любой символ пробела Any whitespace character
\S Непробельного характера Any non-whitespace character
\d Любая цифра Any digit
\D Любой не-цифа Any non-digit
\w Любое слово, символ (буква, цифра, подчеркивание) Any word character (letter, number, underscore)
\W Любой не символ слова Any non-word character
\b Граница слова A word boundary
\B Инверсными границе слова Negated word boundary
(...) Захватить все закрытые Capture everything enclosed
(a|b) a или b a or b
a? Ноль или один из Zero or one of a
a* Нуль или больше Zero or more of a
a+ Один или несколько One or more of a
a{3} Ровно 3 из Exactly 3 of a
a{3,} 3 или более 3 or more of a
a{3,6} Между 3 и 6 Between 3 and 6 of a
(?:...)
Номера для группы захвата Non-capturing group
(?>...) Атомной группы (не отступать) Atomic group (does not backtrack)
(?|...) Дубликат подшаблоном группы. Duplicate subpattern group.
(?#...) комментировать Comment
(?'name'...) Именованные группы захвата Named capturing group
(?<name>...) Именованные группы захвата Named capturing group
(?P<name>...) Именованные группы захвата Named capturing group
(?JismxXU) Встроенные модификаторы Inline modifiers
(?(...)..|..) Условный (IF) заявление Conditional (IF) statement
(?R) Recurse всей картины Recurse the entire pattern
(?1) Recurse первый подшаблоном Recurse the first subpattern
(?=...) Положительный просмотр вперед Positive Lookahead
(?<=...) Положительный просмотр назад Positive Lookbehind
(?!...) Отрицательный просмотр вперед Negative Lookahead
(?<!...) Отрицательный просмотр назад Negative Lookbehind
(*...) Глаголы Verbs
\A Начало строки Start of string
\G Специальные якорь, полезные с / г Special anchor, useful with /g
\p{..} or \p.. Свойств символов Юникод Unicode character properties
\z Конец строки End of string
[abc]* 0 или более, В и С [жадный] 0 or more of a, b or c [greedy]
[abc]*+ 0 или более, В или С [притяжательные] 0 or more of a, b or c [possessive]
[abc]*? Ноль или более из A, B или C [ленивый] Zero or more of a, b or c [lazy]
\Q...\E Цитата; Рассматривать как литералы Quote; Treat as literals
[[:alnum:]] Posix стиле символ класса Posix style char class
     
     
     
flags: i: case insensitive m: make ^$ match start and end of line respectively s: make dot match newlines g: all matches
Флаги: i : без учета регистра m : сделайте ^ $ начала матча и в конце строки соответственно s : сделать перевод строки точка матч g : Все матчи

http://msdn.microsoft.com/ru-ru/library/az24scfc.aspx

http://regex101.com/

XNA прямая загрузка контента

В XNA (и в MonoGame) можно загружать контентна прямую

Texture2D  myTexture;
System.IO.Stream stream = TitleContainer.OpenStream("Content/picture.jpg");
myTexture = Texture2D.FromStream(GraphicsDevice, stream);

LINQ vs foreach измерение скорости работы

Я вспомнил что давно хотел прояснить для себя вопрос, насколько использование LINQ быстрее/медленнее циклов.
Оказалось, к моему сожалению что медленнее, а массивы оказались быстрее листов.
Немного вступления. Когда появился LINQ он показался мне чем-то страшным и только для работы с базами данных. Через некоторое время я полюбил его. В самом деле, писать типизированные запросы к базе данных на нам настоящее удовольствие. И так постепенно он плотно вошел в мою жизнь. Я забыл все алгоритмы сортировки и поиска и полностью стал использовать LINQ. Но никогда не задумывался, а насколько быстро он работает. И вот вечером, после прочтения статьи о том что массивы быстрее листов (я думал на оборот) я решил проверить.
Для этого быстро написал код, коллекции и массивы я решил заполнять случайными значениями, при старте приложения. Размер массивов/списков 10000000 элементов. Замеры я делал на релизном билде с отпимизацией (.net4.5).
Ну что, начнем, для начала строки:

var result = stringList.Where(w => w.Contains("ab")).ToList();

против

var result = new List<string>();
            foreach (var item in stringList)
            {
                if (item.Contains("ab"))
                {
                    result.Add(item); 
                }
            }

И что в результате?
3480 мс. против 2360 мс. 
А если в место листов используются массивы то 2542 мс. против 2122 мс.
Да, вот так, почти секунда разницы. Как вы понимаете LINQ проиграл, так же, как и листы.
Грубо говоря мы теряем 35% производительности на LINQ запросах.
На массивах мы теряем всего 15% на LINQ запросах.

Теперь числа:

var result = intList.Where(w => w > 300 && w < 1000).ToList();

против

var result = new List<int>();
            foreach (var item in intList)
            {
                if (item > 300 && item < 1000)
                {
                    result.Add(item);
                }
            }

314 мс. против 184 мс. и 188 против 165 для массивов. Ну чтож, опять LINQ проиграл. Причем разница уже в 42% для листов и 13% для массивов.
Последняя надежда остаётся FirstOrDefault() может сейчас вырваться вперед?

var result = intList.Where(w => w > 300 && w < 5000).FirstOrDefault();

против

int result = 0;
            foreach (var item in intList)
            {
                if (item > 300 && item < 5000)
                {
                    result = item;
                    break;
                }
            }

51 и 45 мс. в этот раз 22%, и  foreach опять победил.

Я запускал несколько раз приложение, и результат всегда был одинаковый от 20% до 45% процентов увеличение времени выполнения по сравнению с foreach.
Интересно, чем обусловлено такое поведение? Я думаю, что лишнее время тратиться на создания дерева выражений, и возможно какие-то еще функции.
Вот так, за красивый и хорошо читаемый код нам приходиться расплачиваться скоростью работы. С другой стороны в обычных приложениях несколько десятков миллисекунд задержки будут не критичны, но в высоконагруженных проектах это может стать большой проблемой.