RabraBabr

В саппорт к провайдеру. Или в сетевые монтажники, провода тянуть.
Или на ставку админа в бюджет - школы-больницы-библиотеки - там ставки копеечные, но скиллы качаются с трехкратным бустером :)

Да, работа с сегментом данных и стеком значительно легче для процессора, и потому их используют везде, где можно. Куча используется в четырёх основных сценариях.
1. Выделение большого количества данных, которые стек вместить не может. Пример: матрица на много-много мегабайт.
2. Выделение не известного заранее количества данных. Обычно «не известное заранее» = «возможно, большое», но и тут есть интересный пример: даже если 1000 символов на строки нам хватает за глаза, строки используются настолько часто, что слишком уж расточительно на каждую строку пускать по килобайту.
3. Сложное время жизни объекта, не ограниченное рамками функции. Примеры могут быть в играх: функцией Spawn объект появляется, функцией Kill уничтожаем.
4. Использование виртуального полиморфизма (см. ООП). Игровые позиции, как ни странно, плохо совместимы с ООП, так что давайте будет так: функция CreateStream может создать поток, работающий с отрезком памяти или файлом.

Указатель может иметь такие значения.
• Единственная «ниточка», ведущая к объекту в куче. Все указатели перенаправили, а объект не уничтожили — всё, кусочек памяти «висит».
• Некие «стрелочки», налаженные между объектами, чтобы устроить связный список, дерево или что-то ещё. Независимо от того, какие объекты: мы вполне можем в небольшой игре создать кучу объектов с запасом, скажем, в сегменте данных или даже стеке, и налаживать между ними такое же взаимодействие, как будто они в куче.
• Просто «стрелочка» на кусок памяти, которую принимает или отдаёт функция. Причём эта стрелочка может указывать и в пустоту (nullptr). Всё, что функция изменяет по этой стрелочке, будет видеть и вызывающая программа — в отличие от передачи по значению. Или просто объект такой большой, что его копировать бессмысленно. Или архитектурно некопируемый (системный ресурс вроде открытого файла).
• Арифметика указателей позволяет работать с кучей объектов, которые сидят рядом в памяти. В Си++ есть понятие «итератор» — объект, похожий на указатель и обладающий арифметикой указателей, но позволяющий пробежаться, например, по дереву поиска.
• Опять-таки, виртуальный полиморфизм приводит к тому, что к нам приходит не-знамо-что не-знамо-какого устройства (мы лишь знаем, что этот объект, скажем, умеет читать данные как из файла) — обращаться к таким объектам можно только через указатели. В отличие от предыдущего примера с итераторами, мы не понимаем даже самых основ объекта — сколько он байтов занимает, как его создавать, копировать и уничтожать (часто в интерфейс объекта входят столь же виртуальные команды «сделать копию» и «уничтожить», но это отдельный вопрос).

На ссылку смотрите как на указатель, который 1) не может указывать в пустоту; 2) надо обязательно сразу же присвоить и дальше не перенаправлять. Самое то, когда функция принимает или отдаёт «стрелочку» на кусок памяти, и стрелочка никогда не может указывать в пустоту.

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

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

Зависит от компилятора и заданных при компиляции опций. Например, при плотной упаковке (#pragma pack(1)) каждый элемент структуры занимает ровно столько, сколько ему необходимо. А при выравнивании на 64 бита (#pragma pack(8)) под каждый элемент выделится память, кратная 8 байтам и достаточная для размещения элемента. Для разных архитектур процессоров могут быть доступны разные настройки выравнивания.

Знаю только одну книгу на русском по С++20: https://dmkpress.com/catalog/computer/programming/... Хотя пристально вопрос не отслеживаю, возможно появилось что-то еще в других изданиях. Эта книга совсем не учебник - вы не научитесь по ней программированию на С++.
Тем более вы не найдете учебник, где бы был описан 20 стандарт. Возможно на английском есть.
Вообще книги формата учебников подтягиваются к современным стандартам с большим запозданием - лет 5 это норма. В любом случае Прата подойдет для изучения языка. После него можно углубить изучение каких-то вопросов, по которым остались пробелы и изучить нововведения поздних стандартов.

Очевидно, потому что возвращаемый тип имеет определенный оператор преобразования к int или long, но не имеет переопределенного operator+ с int.

Если смотреть описание возвращаемого типа, то там есть operator+ с каким-то streamoff, а с int - ничего нет. Там, правда, не указано, что есть опретор преобразования к int, так что это, наверно, тоже лучше не использовать.

struct message{
    int id;
    char* data;
};
…
send(fds[i].fd, &msg, sizeof(msg), 0)

Этот send отправляет клиенту не данные, а указатель. Указатель на данные, которых у клиента нет.

// Add new socket to poll array
            fds[nfds].fd = new_socket;
            fds[nfds].events = POLLIN;
            nfds++;
        }
 
        // Check for data from clients
        for (int i = 1; i < nfds; i++) {
            if (fds[i].revents & POLLIN) {

Здесь ты добавил сокет в массив дескрипторов полл и сразу проверяешь, не установлен ли у него revents. Но это поле в этот момент не инициализировано. Мало того, ты просишь ожидать POLLIN, но клиент никогда ничего не отправляет серверу, поэтому и сервер не дождавшись POLLIN никогда ничего не отправляет клиенту.

struct pollfd fds[1];
    fds[0].fd = sock;
    fds[0].events = POLLOUT;
    if (poll(fds, 1, -1) <= 0) {
        perror("poll failed");
        exit(EXIT_FAILURE);
    }
    if (!(fds[0].revents & POLLOUT)) {
        perror("connect failed");
        exit(EXIT_FAILURE);
    }

    // Receive message from server
    while ((valread = read(sock, &msg, sizeof(msg))) == -1 && errno == EAGAIN);

Здесь ты ждёшь до POLLOUT, но после этого начинаешь читать. Это малость нелогично, потому что наличие данных для чтения показывается флагом POLLIN. POLLOUT же на свежеустановленном соединении есть сразу, поэтому чтение тупо вертится в цикле while пока не прийдут данные.

как это можно попробовать подебажить понять что не так, что происходит

Можно тупо повставлять печать в ключевые места, что да, соединение установлено, соединение принято, полл завершился успехом, данные отправлены, данные приняты.

Потому что шаблон.

Надо или весь класс определять в хедере, или в array.cpp указывать компилятору генерировать инстанс шаблона с параметром, который нужен в другом cpp файле:
using Array<int>;

То же и для очереди.

Происходит это потому, что компилятор генерирует шаблоны лениво - только когда они нужны. Вот, компилируя array.cpp он не видет вообще ни одного использования шаблона и не генерирует ничего. В каком-нибудь main.cpp у него есть объявление из array.h и использование шаблона. Он и генерирует объявления методов. Но определения-то нигде нет. Оно в array.obj должно быть по вашему замыслу, а там пусто.