res2001

Зачем так сложно читаете в read_block?
Возможно из-за того что у вас возвращаемое ReadFile значение никак не обрабатывается и случаются эти пропуски.
Если у вас в буфере приема порта что-то лежит - это не значит, что ReadFile гарантированно завершиться синхронно.

Я бы сделал синхронный ReadFile в цикле с проверкой количества прочитанных байт.
Учитывая, что и запись и чтение в вашей реализации по сути синхронные, то нет смысла усложнять асинхронщиной.

так:
// удален не верный пример
или так:

int* discribeTwoDimensional() { 
  ... 
  return (int*)masInt; 
}

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

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

Параллельные вычисления могут быть разными.
Можно например MPI использовать или OpenMP, или SIMD инструкции процессора (intrinsic) или вычисления на GPU.
То же вполне себе параллельные вычисления. По этим темам отдельные книги, по SIMD intrinsicам мануалы от Intel, про GPU - соответствено от Nvidia или AMD.

По многопоточности в С++ есть:
1. Энтони Уильямс "С++. Практика многопоточного программирования"
2. Райнер Грим "Параллельное программирование на современном С++"

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

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

Можно вместо файла использовать какой-то параметр в реестре.

Все это можно сделать на батниках.

У вас ошибка появляется из-за опции -Werror=conversion компилятора. Она заставляет компилятор генерировать ошибки при любом неявном преобразовании, в котором есть вероятность потери данных или изменении значения. А в этой операции такая вероятность есть по формальным признакам.
Тут можно либо убрать опцию, либо, применить явное преобразование к unsigned int:20

Согласен с jcmvbkbc по поводу отказа от битовых полей.
Хотя опция -Werror=conversion добавит проблем и без битовых полей, но, с другой стороны, она заставляет глубже понимать, то что вы написали.

Вообще по пользователям в реестре: \HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
Если нужен только текущий пользователь, то переменная окружения %USERPROFILE%

Пользовательский профиль можно переместить весь, тогда изменения будут в USERPROFILE и в реестре.
Но можно переносить и отдельные папки профиля в другое место. Тут уже не знаю точно как винда это хранит. Из возможных вариантов:
1. где-то в пользовательском реестре лежит новый путь
2. вместо стандартного каталога записывается ссылка на новое место

Команда ftp поддерживает скрипты, которые можно передать команде через опцию -s.
Скрипт просто содержит список стандартных команд ftp, которые нужно выполнить.

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

Начать стоит с запуска в консоли ftp и сделать то что вы хотите руками. Заодно освоите команды ftp и разберетесь, что писать в ftp-скрипты.

Если x и y - это min и max, то у вас ошибка:
if (b[i] >= x || b[i] <= y)
надо
if (b[i] >= x && b[i] <= y)

Копировать элементы можно с помощью std::memcpy, а не в цикле поэлементно.

В Си, да и в С++, стандартные целочисленные типы, поддерживаемые компилятором - это char, short, int, long long и их беззнаковые братья. Стандарт действительно не фиксирует размеры стандартных целочисленных типов. Это сделано потому что стандарт описывает абстрактный язык, который должен компилироваться для разных платформ.

Компилятор же компилирует программу под конкретную платформу с конкретными соглашениями по типам. Ему заведомо известны размеры стандартных типов на данной конкретной платформе. Стандартная библиотека так же обычно пишется под конкретный компилятор и конкретную платформу.
Так что (u)intX_t - это всегда define над стандартными типами. И ничего странного в этом нет.

в forе проверяйте текущий файл только на вариант SEND_2 и сразу делайте переход, если из forа выйдет без перехода - значит это COPY_2.

Массив может быть представлен по разному.
Для статического массива sizeof(arr) сразу возвращает размер массива в байтах.
Для указателя на массив sizeof(ptr_arr) возвращает размер указателя. Чтоб получить размер массива в этом случае надо сделать sizeof(ptr_arr[0])*N.
Когда вы передает в функцию статический массив, то внутри функции это все равно указатель (не смотря на то, что в аргументе он может быть объявлен как int arr[N]) и sizeof над ним ведет себя как с указателем, а не как с массивом.

Вариант sizeof(arr[0])*N будет правильно работать как с указателем так и со статическим массивом.
При этом реального обращения к памяти arr[0] не происходит, поэтому этот вариант можно использовать даже в таком случае:

int *ptr_arr=NULL;
size_t size_arr = sizeof(ptr_arr[0])*N;

Почитать книжку "Многопоточное программирование на С++". Там не про сокеты в многопотоке, а просто про сам многопоток. Многопоточная обработка сокетов не сильно отличается от любого другого многопотока.

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

Как альтернатива для случая не слишком большого количества клиентов - один поток + неблокирующие сокеты + асинхронная обработка.
Про работу сокетов в неблокирующем режиме можешь почитать: "UNIX: Разработка сетевых приложений" книжка старая, но актуальная. В магазине скорее всего не найдешь, но в интернете полно сканов.
Книжка хороша не только по неблокирующим сокетам, а в принципе как описание разработки сетевых приложений.

Отдельный вопрос - кросс-платформенное приложение. Книг на эту тему вроде не видел, но подходы имеются. Не то что бы это сложно, но есть своя специфика.

Никто ничего не дописывает. Дело в специфике хранения данных в числах с плавающей точкой.
Эти числа всегда приближенные. Грубо говоря даже какое-то целое число, типа 3, будет храниться как: 2.9999999999999999999.
Конкретно 3 будет иметь точное представление, но другие числа будут иметь приближенное представление. Поэтому работая с числами с плавающей точкой лучше всегда иметь ввиду, что это число приближенное.
Можете почитать что-нибудь по стандарту IEEE754 - стандарт чисел с плавающей точкой, который сейчас используется повсеместно. Так же в интернете есть сайты, где можно глазами увидеть как представляется то или иное число с плавающей точкой в компьютере. Например можете тут посмотреть: https://www.h-schmidt.net/FloatConverter/IEEE754.html

Попробуйте в include_directories() указывать полные пути. Стандартная переменная cmake ${CMAKE_CURRENT_SOURCE_DIR} содержит путь где лежит текущий файл cmakelists.txt, ее можно использовать для генерации полного пути.
Обычно, если в проекте используется иерархия каталогов, то в каждом каталоге с исходниками лежит свой собственный cmakelists, а подключается он к нижележащему через add_subdirectory(). Собирайте в каждом каталоге свою цель (статическую библиотеку), потом эти цели указывайте в зависимостях для основной цели.