#

Прочтите обе - не ошибётесь.

Если из этих книг выбирать, что читать 1м, то я бы сначала рекомендовал читать Албахари. Это более общая книга и она именно про язык C#, про синтаксис и ключевые концепции, как их использовать.
CLR via C# Рихтера уже не совсем про C#, она рассказывает о CLR используя в качестве примера один из языков поддерживаемых CLR, т.е. C#. Эта книга больше про внутреннее устройство, она посложнее на мой взгляд. Там есть очень специфические разделы, которые вам могут не сразу (или никогда) не пригодится. Её стоит пробовать начинать читать, если не получается, то окладывать и пробовать позже. Она интересна с той стороны что Рихтер является консультантом Microsoft, некоторые из ключевых частей dotnet framework разрабатывал он. Интересно посмотреть внутреннее устройство, почему сделано так или иначе. Она становится интересной когда начинаешь задумываться о производительности, о блокировка, о многопоточности.

Итого: читать обе, сначала Албахари, потом Рихтера. Отдельные темы Рихтера перечитывать по необходимости.
И на этом не останавливаться, кстати. Дальше можно, например, взять книгу "Pro .NET Performance" если придется серьезно заниматься оптимизацией. Или еще какую. У меня например накопилось пара полок книг. И по C# и по смежным темам.

PS
А на работе у нас лежат: 3е издание CLR via C# и 4е издание CLR via C#, а также 3е издание C# in Depth и 2е издание C# in Depth. И если выйдут новые издания, мы их скорее всего купим тоже.

как быть? Какой размер массива объявить?

Не объявляй никакой. Воспользуйся вместо этого стандартным контейнером, например std::vector.
Но если хочется помучаться -- воспользуйся указателем и выделяй память динамически, по мере поступления входных данных.

Если коротко исторически так сложилось.

В который раз встречаю человека который упорно не желает пользоваться STL. При том это какое то иррациональное нежелание.

А теперь длинно.

Хочешь плохому научу?
Выделяй память malloc'ом, а когда надо изменить размер "массива", пользуйся realloc'ом. Можешь так же как в встроенном массиве пользоваться [] для обращения к элементам массива.

Дальше напиши какую нибудь серьезную программу тыщ хотя бы на 20 строк. И в один прекрасный день узнай, что она крашится в самом неожиданном месте, хотя раньше все работало. Далее две бессонных недели, с красными глазами проведи с отладчиком в поисках неуловимого бага. После чего совершенно случайно найди место где вылазишь за пределы массива или обращаешься к неинициализированной памяти. Вот после этого станет понятно, что так жить нельзя. И вот все это безобразие размазанное по всему коду надо собрать в одном месте. И все проверки и инициализацию делать там. А где это в одном месте? Правильно написать собственный класс, там и конструктор есть для инициализации по умолчанию и [] перегрузить можно, что бы всякие проверки делать и деструктор, что бы за собой прибрать. А потом тебе захочется, что бы твой класс работал с разными типами данных и ты перепишешь его на шаблонах.

А теперь загляни в стандартную библиотеку. Поздравляю все это уже давно сделали за вас гораздо лучше и со множеством приятных плюшек. Тысячи программистов прошли этот путь за более чем 40 лет. Так зачем, зачем проходить этот путь еще раз? У вас, что есть запасная жизнь? Берите и пользуйтесь готовым. C++ имеет тысячи подходящих инструментов. Пользуйтесь ими. Так нет каждый новый адепт хватает кирку и лопату и бежит строить днепрогэс. Не надо построили уже до вас. Вы в стандартной библиотеки поищите оно там есть.

Открыл вопрос и из монитора хлынул поток воды, так что сразу к вопросам:

Какое оборудование (модели) ставить на уровень доступа, распределения?

Да Микроты ставьте, если прокачаться хотите. В качестве свитчей - HP, например. Можно и D-Link, не слушайте диванных кукаретиков.

Как делать - 4 коммутатора на все устройства (в шкафу), или же по одному на этажах и центральный в серверную?

Всё в шкаф, чтоб потом не бегать по этажам и не искать причину поломки.

Как нарезать vlan? По этажам? По кабинетах?

По кабинетам геморройно, я бы вообще ничего не делал, сеть-то маленькая.

Так и не знаю делать ли интернет розетки или нет)

По уму - надо бы сделать всё грамотно, с нуля, с перфорацией, кабель-каналами и маркировкой, но лично я бы этим занимался, если бы зарплата шла от 70+ тыр минимум без последующих уменьшений и увольнений.

А, да, и AD бы всё-таки настроить и DNS с DHCP на Windows Server зарулить.

Когда советуют, убедитесь, что у вас и у аудитории этого совета одна цель. Потому что "как можно скорее начать пользоваться фреймворками" - это если задача - как можно скорее начать шлёпать продукт и деньги получать. А если задача - научиться программировать, фреймворки тут не при чем.

Понадобилось сделать аппроксимацию полиномом m-й степени...
Подозреваю ограничение точности double...
В чём может быть проблема?

При решении таких задач хорошо бы опираться не на подозрения, а на математику - Феномен Рунге. Эта тема обычно проходится в универах в рамках курсов по вычислительной математике (ах, какая нелепость это ваше высшее образование). Или можно хотя бы погуглить "интерполяция полиномами высоких степеней". Тема изучена вдоль и поперек уже сотню лет как.

Очень хороший вопрос и тема, в которой самое чудовищное количество самых дремучих северий на единицу кода.

В общем случае, по умолчанию, никаких проверок и траев с кетчами быть не должно.

Я понимаю, что это звучит богохульством для среднего пользователя похапе, но в реальности программы пишутся совсем по-другому.

Пример: В обоих приведенных выше случаях мы имеем масло масляное: попытка подменить пхп в выборосе ошибки. Вопрос - зачем? Если файл не найден, то РНР сам прекрасно сообщит нам об ошибке, причем в подробностях, и скажет в чем конкретно заключается проблема. А по строчке "file not found" иди гадай - путь ли кривой или в имени файла опечатка, или вообще пустоту передали.

Любые проверки надо делать только тогда, когда есть осмысленный сценарий их обработки.

И обсуждать выше приведенные примеры имеет смысл только если автор вопроса предоставит такой сценарий. тупое error: file not found таким сценарием не является. Так что в общем случае оставляем код в покое и не устраиваем никакого карго культа из перехвата ошибок.

Если чисто выбирать между двумя действиями (проверка и чтение) и одним (сразу читаем, потом ловим исключение),

то последнее предпочтительнее, поскльку это атомарная операция, в то время как между проверкой и чтением состояние системы сожет измениться (файл может быть удален).

Но повторюсь, если нет никакого осмысленного сценария обработки ошибки, то ловить её не надо.

Беру CCleaner, чищу реестр.

Руки оторвать, и выгнать из профессии.

Дефрагментирую диск

Отправить лечиться от идиотизма.

Как вы улучшаете «скорость» работы компьютера?

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