oleg_ods

Неплохая книга для "нулёвых" новичков, которые хотят делать игры в Юнити.

В главах 1-5 рассказывают самые базовые вещи языка (переменные, ветви/циклы, методы) и самые простые вещи, связанные с классами. За эти главы научиться программированию невозможно, для них цель - дать нужные термины, с которыми потом можно идти дальше. Потом эти же вещи обрастут нужными подробностями и примерами во второй и третьей частях.

В главах 6-9 больше автор говорит о Юнити, тоже довольно коротко, но если читатель хоть немного уже раньше ознакомился Юнити, то тут будет попроще. Хорошо то, что здесь рассказано, как писать скрипты о нужных частях игры, о которых рассказывает - движение объектов в скрипте, физика, поведение объектов, а также коротко о программировании ИИ (некоротко не получится - об этом пишут толстенные тома).

Главы 10-12 углубляют понимание языка и добавляют новые концепции (разные коллекции, дженерики, делегаты, обработка ошибок). Тут поменьше кода и побольше теории. Но и тут каждый факт о языке подкрепляется примером.

В общем, в книге показаны основы программирования на языке c# и его использование для создания базовых скриптов в Юнити. Некоторым минусом могу отметить, что тут автор больше учит собственно языку, а не программированию - то есть, как писать, а не почему писать так. Но такое в подобных книгах и не пишут - понимание приходит позже, с опытом.

Потому что IntPtr это машинное слово, и если у вас не древний мамонт, то но равно 64 битам (оно же long). И оно никак не может поместиться в ваш int

Чтобы отработал конструктор базового класса, иначе не создать объект.

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

Это, по сути, наследование. Абстрактный класс-предок (поставщик) и конкретные классы-потомки (физлицо, ИП, организация). Наследование обычно выражается в структуре БД так: создаётся таблица "Поставщик", содержащая общие для всех классов поля и имеющая свой ключ.
Затем под каждый класс-потомок создаётся отдельная таблица, содержащая сведения, уникальные для этого класса. В этой таблице первичный ключ одновременно является внешним ключом, ссылающимся на таблицу "Поставщик". Иными словами, в таблице-потомке могут быть только записи с ключами, которые есть в таблице "Поставщик", а для каждой записи в "Поставщик" будет не более одной записи в таблице-потомке.

В таблице "Поставщик" также может быть поле, указывающее на конкретный тип поставщика (физлицо, ИП, организация), т.е. в какой таблице искать остальные данные. Наличие или отсутствие этого поля - вопрос вкуса. В принципе, если нам нужны сведения о конкретном типе поставщика, мы можем попытаться сделать INNER JOIN с нужной конкретной таблицей. Это отсеет все записи других типов.
Такой подход (без поля типа) позволяет избежать противоречий, когда запись находится в одной таблице-потомке, а поле указывает на другую. Но с другой стороны, если мы не знаем, какой конкретный тип у данного поставщика, нам придётся либо перебирать таблицы-потомки в рамках нескольких запросов к БД, либо делать LEFT JOIN со всеми таблицами-потомками, и смотреть, какие поля не будут NULL.

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

C# 4.0 это очень древний, нет смысла его читать. Microsoft каждый год планируется выпускать новую версию .NET, старые версии поддерживаются +- 3 года.
Конкретно за книги, они учат логики и философии кодинга, где можно рассказать примеры и объяснить принципы работы "Водой", что является очень важным аспектом, т.к. при собеседовании на фирме вам будут давать [возможно] тесты по языку и фреймворку, а так же тестовое задание, где будет оцениваться как работоспособность проекта, так и правильность написания.
Если смотреть в сторону профессиональных курсов, то вас будут ругать даже за неправильно названные переменные, это уже если не говорить об самой логике написния задачи.
Цель подобных книг - закрепить понимание языка, а не зазубрить синтаксис. Тот же metanit показывает сугубо синтаксис и как правильно его юзать, но он вас никогда не будет учить, где его использовать, как и при каких условиях, почему этот метод плох, а где он будет незаменим.
Но для новичков лучше не наседать на книги, а делать упор на практику, но без "поводыря" очень сложно, т.к. если у вас не понимания самой логики построения, вам будет очень сложно что-то делать в будущем.

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

Насчет чят бота не скажу. Вообще скажу.

Если задача связана с вычислением численных метдов например. Или рендерингом 3D. Или крипто-майнингом. Или нейро-сетей - где
CPU -> 100%, I/O -> 0% то тогда тебе прямая дорого в мультипоточность (мультипроцессность). Количество тредов расчитывается обычно по формуле = количество ядер (иногда АЛУ/Threads) умноженное на коєффициентик. Подбирается экспериментально для конфигурации и среды исполнения. У меня для Java-11 выходило что на 4 ядра Core-i3 надо было 5 вычислительных потоков.

Если в задаче главным дирижёром является канал I/O а нагрузка на расчет малаая (парсер) - то используют технологи асинхронизма. Это когда ваши вычисления подписываются на события I/O и 80% времени ничего не делают а только ждут события от I/O. При благоприятных условиях хендлеры могут потреблять вообще 0% ресурсов. Нет событий. Поэтому таких хендлеров можно поднять очень много. Пример - акторные технологии. Хендлер. Актор. Горутина. Пример 10 000 акторов обслуживается 10 потоками исполнителями.