VoidVolker

Чтобы решать математическими методами - да, нужно знать математику. В частности дискретную, тк чаще именно её использую при решении алгоритмических задач.

Книга есть. Начать можно с достаточно толстой: Алгоритмы, построение и анализ.
Например там в начале показан пример, как найти (или хотябы доказать корректность) решение при помощи индукции, доказывая, что на каждом шаге алгоритма будет выполняться какой-то инвариант (например что вся левая часть массива отсортирована после того, как мы перешли к правой)

Давай слегка тормознем твой поток созднания. Слишком много у тебя тезисов.
В каждом языке программирования есть свои числовые литералы. В си-шарпе - свои.
И в ассемблере свои.

Попробуем ответить на первый.

А могул ли быть, А100000000000000h, то есть начаться с А

Да могут быть. В хекс-системе числа состоят из цифр и букв от A до F. Другое
дело что ты должен следить за разрядностью и понимать что в регистр процессора
(ассемблер) и тип данных (для шарпов) может влезать ограниченный диапазон
величин. Например для ассемблерного двойного слова (DWORD) максимальное число FFFFFFFFh
И для шарпового unsigned long максимальное 0xFFFF_FFFF_FFFF_FFFF

Тоесть правильный ответ состоит из проверки числа на допустимые символы и проверки
ТИПА данных на диапазон.

Потому что символы # перед if else не нужны. При такой записи эти инструкции будут рассматриваться как директивы препроцессора, которые тебе здесь не нужны. В вашем коде происходит проверка дефайнов (#define) предпроцессора. Поскольку вы не объявили что-то вроде:
#define number 2
то препроцессор отдает на компиляцию следующий код:

int number, wrong;
printf("Введите номер (1-5):\n");
scanf("%d", &number);
printf("Вы ввели неправильное число");
printf("\n%d", wrong);
return 0;

То есть в момент исполнения программы просто нет никакого if. В общем, подтяните знание языка
Вам нужно что-то такое:

int main() {
    int number, wrong;
    printf("Введите номер (1-5):\n");
    scanf("%d", &number);
    if (number>1 && number<5) {
        printf("Вы ввели правильное число: %d", number);
    } else {
        printf("Вы ввели неправильное число: %d", number);
    }
    return 0;
}

Ой хоспаде, что это такое :DD
"#команда" - это команда (директива) препроцессора, и это совсем не та часть языка C++, которая помогла бы тебе сделать то, что ты пытаешься сделать.

Правильно было бы вот так:

if ((number > 1) && (number < 5))
{
    printf("Вы ввели правильное число");
}
else
{
    printf("Вы ввели неправильное число");
}

Согласен с Voland69, API обычно умеют ограничивать кол-во результатов на уровне запроса. Это было бы самое технически правильное решение, а так, ответ выше дали

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

Event listener — буквально так и переводится: "слушатель события". Т.е., когда мы назначаем элементу путём addEventListener некий обработчик, мы заставляем его слушать и реагировать на некоторое событие, возбуждается чем-то.

К чему я это… В таких неопределённых ситуациях всегда лучше делегировать слушателя, а иногда без этого просто не обойтись, особенно когда дело касается "мышиной возни" (MouseDown, MouseOver etc). Делегирование слушателя одному из предков, к тому же, имеет ещё одно неоспоримое преимущество: при динамическом изменении DOM, например при загрузке по ajax пресловутых элементов .mobile-categories, не нужно следить за прикреплением им слушателей каждый раз.

document.body.addEventListener('click', (ev)=>{
    if (ev.target.classList.includes('.mobile-categories')) {
       // Тут что-то делаем с ev.target
    }
});

У bun потенциально может быть быстрее старт приложения за счет использования движка JavaScriptCore вместо V8 в node/deno. Вот только у V8 на сегодня поддержка всех нюансов ECMAScript самая близкая к 100%. А старт рантайма происходит лишь 1 раз во время жизни приложения. Считать ли это профитом - вопрос философский.
Ну и ИМХО, если биться за скорость путем смены движка, то я бы лучше взял QuickJS.

Еще потенциальный выигрыш может быть за счет переписывания тех частей, что в node реализованы на JS. В node на самом деле очень многое на JS сделано. 100% встроенных модулей написано на JS, где уже под капотом дергаются функции из C++. Я не смотрел исходники deno/bun, но экспериментировал с v8 на Rust (спасибо deno за нормальный биндинг). Работать это будет быстрее, вот только обрабатывать JS Promise из нативки то еще приключение, и хочется делать это пореже за счет JS прослоек, как собственно и происходит в node.
Rust (deno) и Zig (bun) по скорости сравнимы с плюсами (где-то быстрее, а где-то медленнее, но в среднем примерно одинаково). Самый большой оверхед в языках с рантаймом создает рантайм (сборка мусора, JIT компилятор и т.д.), у C++, Rust и Zig подкапотного рантайма почти нет, у JS - целый V8/другие движки.

Ну и еще момент, что bun, что deno работают с ts из коробки. Вот только TypeScript - это язык у которого нет спеки, есть открытый код компилятора (в котором черт ногу сломит), есть release notes, а спеки нет. А значит гарантировать 100% совместимость с tsc не может никто. Хотя это проблема не только этих сред, но еще и WebStorm и babel-typescript например. Хотя на сколько понял они пошли путем babel - просто затранспайлить (по сути выкинуть все типы), вот только babel в некоторых кейсах все же ломает код...

Потому что при проектировании REST API так обозначать ресурс правильнее.

Человечество развивается, люди становятся умнее, начинают наконец понимать стандарты. Ну, кроме разработчиков битрикса, конечно.

В столбик. Точно так же как обычные десятичные числа, только помните, что цифры 8 нет. Если получилось больше 7, все остальное, поделенное на 8 переносится дальше.