AM5800

Мне помогло олимпиадное программирование.
Очень быстро становится очевидно, что выгоднее сразу написать без ошибки, чем потом мучительно ее искать.
В общем, приходилось заставлять себя быть более внимательным с этими индексами. И со временем стало проще.

Но вообще, самый лучший способ избегать offbyone ошибок - это не использовать индексы вообще.
Свертки там всякие. For each вместо for и прочее. И вообще, больше стандартных алгоритмов/функций.

Вот пример для C++: допустим, вам нужно взять последний элемент массива длины n. Тогда индекс этого элемента будет равен n-1. Вот вам и возможность ошибиться. Но если использовать вместо массива vector - то у него уже можно просто взять back().

Вы вызываете SelectMany на string. Следовательно s имеет тип char. Но GetBytes ожидает строку.

Мне почему-то кажется, что вы хотели написать так:
byte[] tmp = K.SelectMany(s => Encoding.Default.GetBytes(s)).ToArray();
Ну или так
byte[] tmp = Encoding.Default.GetBytes(K[i]);

Если маленькие объекты выделяются, а большие нет. И при этом память точно не закончилась - то самая вероятная причина - фрагментирование кучи.
Самый простой способ решить эту проблему - всегда компилироваться в x64.

Не забудьте про алгоритмы.
Отличное введение в алгоритмы здесь: beust.com/algorithms.pdf
Кормен, конечно, тоже прекрасен. Но читать его подряд решительно невозможно.
Здесь же отобраны действительно часто встречающиеся алгоритмы. Есть упражнения. Так что можно совмещать - решать задачки в конце глав и изучать ЯП.

Количество всех подстрок строки n - равно биномиальному коэффициенту (2, n + 1). Т.е. 1/2(n+1)n.
Т.е. в худшем случае у вас n^2 подстрок. А в лучшем - n. Вот только я бы не особо радовался. Так как строки лучшего случая выглядят примерно так: "aaaaaaaaaaaaaaaa". Здесь 16 символов и 16 уникальных подстрок.
Я это все к чему - за линейное время точно ничего осмысленного не выйдет.

Количество уникальных подстрок можно посчитать так:
https://www.quora.com/Given-a-string-how-do-I-find...

К сожалению, автор не дал оценки своего алгоритма. Но, похоже, что он работает за O (n log n).
Так как суффиксный массив строится за O(n log n), а LCP отрабатывает за O(n)

Вы можете получить вашу функцию в виде набора байтов, зная адрес начала и конца функции. С первым все просто. А вот второй... Никаких "честных" способох его получения я не знаю. Но можно, например, зная адрес начала функции, начать ее читать и попытаться найти ее эпилог. Но тут, как всегда в C++ нужно быть осторожным. Эпилог может зависеть от компилятора, его настроек и платформы. Да и сама функция может инлайниться, вызывать другие функции, которые после "копирования" будут недоступны и прочие прелести.

Также можете посмотреть сюда:
stackoverflow.com/questions/4156585/how-to-get-the...

Зависит от того, что там у вас за объекты.
В определенных условиях можно существенно ускориться, если читать поток при помощи BinaryReader'а и руками создавать объекты.

Попробуйте, в общем.

Попробуйте
http://ru.wikipedia.org/wiki/Поиск_в_ширину

Я бы начал плясать от базы данных. Ведь она уже наверняка есть и она может накладывать некоторые ограничения. Т.е. если вы вибираете язык для реализации этой программы - стоит учитывать наличие библиотек для этого языка для работы с этой СУБД. А в остальном сложностей возникнуть не должно

Под windows я бы взял C#. Очень популярный язык, имеет множество библиотек для самых разных СУБД.

Отвечая на ваш вопрос об алгоритме: ни по какому.
У вас здесь происходит каст указателей.
То есть, в первом случае, у вас есть накоторая ячейка памяти, которая содержит число 37. Если на мгновение забыть о типах, то в этой ячейке лежит значение "...0100101"
Когда вы берете ее адрес (&i) - вы получаете указатель типа int. После каста, вы получаете указатель типа float. Изменяется тип указателя, но не данные на которые он указывает. После разыменования и присваивания вы получаете переменную f, значение которой все еще равно "...0100101".

Если же вас интересует именно устройство формата float. То, можно начать отсюда:
en.wikipedia.org/wiki/Single-precision_floating-po...

Предположу, что это сделано, чтобы избежать NPE при вызове stream.Close(), если данный код вызывается одновременно из нескольких потоков. Ведь если написать:
if (stream != null) stream.Close();
То сразу после успешной проверки stream теоретически может стать равным null. При предварительном копировании в локальную переменную это исключено.

По приведенному вами примеру, можно видеть, что номер квартиры равен ID минус количество изменяемых ID, значение которых меньше или равно текущему.
Т.е.
N(2) = 2 — 0 = 2
N(3) = 3 — |{3}| = 2
N(4) = 4 — |{3}| = 3
N(5) = 5 — |{3, 5}| = 3

Т.е. для каждого запроса номера — сложность ответа будет O(m), где m — число изменяемых ID (можно и быстрее).
Если запросов много, то лучше обновить все сразу. Например так:
Перегенерируем все номера начиная с первого так, что номер очередной квартиры равен значению счетчика. Значение счетчика увеличивается на единицу только если текущий ID не равен одному из изменяемых. Иначе — счетчик не увеличивается.
Итоговая сложность — O(n) при условии, что принадлежность ID списку проверяется за O(1).

Честно говоря, очень долго пытался понять суть проблемы. Решение кажется слишком простым. Возможно, я что-то не правильно понял.

Нам в университете прочитали отличный курс алгоритмов на базе книги
Мне очень понравилось

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

Примите за правило прежде чем сломя голову бросаться чинить такие ошибки — сначала написать тест. Со временем придет понимание и что тестировать, и как, а главное — после тяжелых мучений в духе «Блиииин. Ну вот и как написать тест для ЭТОГО?» придет понимание как писать код так, чтобы его можно было тестировать.

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

Еще люто рекомендую системы автоматической сборки и тестирования, описанные в посте Wott'а. Например, у нас после push'а в СКВ — на специально выделенном сервере происходит сборка проекта и запуск всех тестов. Главное преимущество в этом лично для меня — практически нет необходимости гонять тесты на моей машине. Ведь наши тесты могут работать по несколько часов.

Также могу посоветовать различные программы для анализа покрытия тестами. Часто такие программы помимо непосредственно анализа покрытия умеют анализировать и некоторые другие полезные метрики. Например, С.R.A.P. — метрика. Сортировка по такой метрике может помочь обнаруживать сложные, не покрытые тестами функции. Для них стоит писать юнит-тесты в первую очередь.

В верхней части Solution Explorer есть кнопка «Show All Files». После нажатия на нее фильтры исчезнут и вы будете работать с файловой системой.

Наверное, не совсем то, что вам нужно — но как вариант.

Статические классы нужны для объединения глобальных объектов/функций. В частности, часто применяются для создания классов-утилит (Например, для какой-то хитрой печати списка чего-то).

Операция as не совсем эквивалентна приведению через скобочки.
Если каст не удастся — вариант со скобочками сгенерирует исключение.
Тогда как вариант с as — просто вернет null