jcmvbkbc

все это не подходит, так как мне нужно чтобы полученное число c лежало в промежутке [0; 11]

Ну так a * (max(b) + 1) + b же.
Иными словами мы делаем двузначное число в позиционной системе исчисления с неравными весами разрядов, младший разряд -- b, старший разряд -- a. Вес младшего разряда -- 1, вес старшего -- max(b) + 1.

Как получить то же самое в С++?

например так:

uint8_t foo[] = {7, 7};
int i = foo[0] + 256 * foo[1];

В js я могу получить это так
…Int8Array…

Скажи,
- а что будет, если элемент массива foo будет иметь отрицательное значение?
- а что будет, если твой код запустить на архитектуре с порядком байт big-endian?

почему программа завершилась? Вмешалась ОС? Но если так, то почему?

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

Почему я не могу поменять значение самого указателя (ведь указатель - это всего лишь ссылка на адрес памяти, а не на значение).

Значение указателя ты поменять можешь, но это не то, что было написано в коде. В коде было написано поменять значение на которое указатель указывает. Поменять указатель было бы a = (int *)10;

могу ли я указателю дать ссылку на конкретную ячейку в памяти?

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

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

В памяти всё хранится как последовательность байтов. Любую последовательность байтов можно проинтерпретировать как указатель. Но чтобы компилятор С понял что ты имеешь в виду, ему надо явно сказать, что ты хочешь проинтерпретировать целое число как адрес: int *a = (int *)0x0061FF18;

more than one input file specified
nasm -felf64 bin BootLoader.asm -o BootLoader.bin

nasm как бы говорит тебе: "выбери, или ты ассемблируешь bin или BootLoader.asm"
Если же ты хотел формат 'bin', то выкинь -felf64 и замени его на -fbin.
Тебе, правда, при этом прийдётся добавить что-нибудь типа use64 в исходник, чтобы сказать, что он не 16-битный.
Ну и к тому же message у тебя лежит перед кодом, в той же секции, хороший bin из этого не получится.

call of overloaded ‘Point2D()’ is ambiguous

Потому что, похоже, у Point2D<T> больше одного конструктора по умолчанию.

Почему так происходит?

Потому что стандарт С11 (9899:201x 6.7.4:7, черновик доступен тут) говорит следующее про спецификатор inline:

Any function with internal linkage can be an inline function. For a function
with external linkage, the following restrictions apply: If a function is declared
with an inline function specifier, then it shall also be defined in the same translation
unit. If all of the file scope declarations for a function in a translation unit include
the inline function specifier without extern, then the definition in that translation
unit is an inline definition. An inline definition does not provide an external
definition for the function, and does not forbid an external definition in another
translation unit. An inline definition provides an alternative to an external
definition, which a translator may use to implement any call to the function
in the same translation unit. It is unspecified whether a call to the function uses
the inline definition or the external definition.

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

inline void some_inline_func(uint32_t num)
{
    . . .
}

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

Вариантов решения этой проблемы примерно 3:
- определить функцию следующим образом:

extern inline void some_inline_func(uint32_t num)
{
    . . .
}

Такая функция будет доступна из других единиц трансляции.

- либо определить функцию следующим образом:

static inline void some_inline_func(uint32_t num)
{
    . . .
}

Такая функция будет доступна только для данной единицы трансляции.

- оставить в этом исходнике всё как есть, а в каком-нибудь другом определить следующую функцию:

void some_inline_func(uint32_t num)
{
    . . .
}

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

Как мне узнать IP WiFi, к которому подключена ESP?

Никак, но не потому, что "это зависит от настроек роутера". А потому что нет никакого "IP WiFi". WiFi -- это физический и канальный протоколы, IP -- транспортный. Можно подключиться к WiFi и не использовать IP. Может быть "IP шлюза по умолчанию" -- вы получите его по DHCP, но с WiFi он может быть не связан совсем.

Команда сборки:
D:\mingw\mingw64\bin\g++.exe -fdiagnostics-color=always -g D:\running\code\parser.cpp -o D:\running\code\parser.exe

Прости, но как по-твоему mingw должен из этой команды понять, что ты используешь какую-то библиотеку и слинковаться с ней?
Тебе надо выполнить шаги по сборке библиотеки, а потом добавить её в свою команду сборки, типа того:

D:\mingw\mingw64\bin\g++.exe -fdiagnostics-color=always \
-g D:\running\code\parser.cpp \
-L<путь куда ты установил libgq> -lgq \
-o D:\running\code\parser.exe

И я подозреваю, что поскольку gumbo-query это обёртка для gumbo, то когда ты успешно слинкуешься с libgq тебе прийдётся повторить эти шаги и для gumbo.

Чтобы каждый раз не задавать параметры дэймону, ищу как зафиксировать.

aspirantes, написать скрипт в котором проставить нужные параметры. Например:

$ cat > /home/222 <<EOF
#!/bin/sh
exec /home/111 -param1 -param2 "$@"
EOF
$ chmod +x /home/222

Было бы логично увидеть, что происходит вызов deleting dtor внутри которого происходит вызов base object dtor.

было бы логично, если бы ты вызывал delete для объекта. А для объекта на стеке-то зачем delete?

Почему в ассемблерном листинге gcc нет тела деструктора [complete object destructor]?

Есть, просто у тебя какой-то понтовый листинг и ты его не видишь. А из-под gcc -S для твоего кода выходит ассемблерный текст, в котором есть такие строчки:

.globl  _ZN6ObjectD1Ev
.set    _ZN6ObjectD1Ev,_ZN6ObjectD2Ev

внутри виртуальных деструкторов не используется виртуализация

чего это "не используется"? А вот этот пункт стандарта для кого написан?