res2001

KR не учебник и не стандарт, написана давно. Хотя есть довольно свежее издание, но текст не изменился.
Берите Эффективный Си, хотя я не читал эту книгу, но выглядит норм. К тому же написана на основе свежих стандартов, в отличии от KR.
У вас не плохой бэкграунд, сам язык достаточно прост, разберетесь с тонкими местами (массивы, строки, динамическая память, указатели, адресная арифметика) и можно начинать что-то делать.
По функциям стандартной библиотеки полно информации в интернет, например тут
Вообще книг на русском именно по Си не много, возможно это связано с тем, что язык достаточно прост и одна хорошая книга закрывает большую часть потребностей.
Кстати, "экстремальный Си" выглядит то же многообещающе, но это, похоже, уже следующий уровень.

Заверните весь код в input.cpp в namespace input {}
namespace добавляет к символам в объектом файле имя namespace, но т.к. у вас определения в input.cpp не включены в namespace, то в объектном файле эти символа будут без добавления имени namespace, поэтому и undefined reference.

Если говорить о скорости, то компилируемые языки всегда будут быстрее интерпретируемых. Просто из-за разных принципов выполнения программы.
Есть еще языки с JIT компиляцией, типа Java, C# и т.п.
Они могут быть быстрее компилируемых в каких-то случаях, т.к. они точно знают на каком процессоре работают в каждом конкретном случае и могут максимально использовать возможности текущего процессора для оптимизации кода.
В компилируемых языках, как правило, программист собирает программу под некоторую абстрактную архитектуру, например под x64, но у конкретного процессора, на котором будет выполнятся программа могут быть какие-то расширенные возможности, о которых программист (компилятор) не знает во время компиляции (или решает не использовать их для универсальности). При этом JIT компилятор может использовать эти расширенные возможности и добьется лучшей производительности.
Но если поставить в одинаковые условия компилируемые языки и языки с JIT компиляцией, то, думаю, результат будет то же в пользу компилируемых языков. Но в реальности такое (заранее известные условия исполнения для компилируемого кода) встречается не часто.

К слову, в том же питоне (интерпретируемый язык), например, модули для математических вычислений (numpy, scipy, ...) написаны на компилируемых языках (C/C++), поэтому они работают быстрее, чем аналогичный код на питоне без использования этих модулей. Да и сам интерпретатор питона написан на компилируемом языке :)

Скорость не единственный критерий для ЯП. Имеет значение и скорость разработки конкретной задачи и поддержка каких-то возможностей и т.д. и т.п.

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

Практически все задачи можно решить почти на любом ЯП, но есть ЯП, которые хорошо подходят для решения задачи, а есть те, что не очень. В общем, подбирайте язык под задачу.
Например, если вы работаете в вебе, то это JS, php, python, java, C# и еще пачка других
Если это десктоп приложение с GUI, то: Java, C# может быть С++
Если это встраиваемая техника и реальное время, ядро ОС или драйверы: C/C++
Если это ИИ, компьютерное зрение и т.п. computer science: python, R, что-то еще

1. Размер всех типов всегда кратен 8 битам. Просто потому, что минимально адресуемый размер памяти в современных процессорах - это 1 байт. Так что 31 или 33 сделать не возможно. Теоретически можно сделать, например, 24 или 40, но смотри следующий пункт.
2. Все базовые типы С/С++ однозначно проецируются на типы данных, поддерживаемые процессором. Поэтому реально использовать только типы, которые поддерживаются железом. А их не так много и все они, скорее всего, уже есть среди базовых типов С/С++.

Да можно использовать вариант с битовыми полями или библиотеки для длинных чисел и т.п., но вычисления в этом случае будут медленные, т.к. все операции придется реализовывать программно. Кроме того, если взять битовые поля - там вы можете определить поле размером в 31 бит, но переменная все равно будет занимать 32 бита в памяти (см п.1).

Читайте тут до прояснения раздел "Bitwise shift operator.
Смысл в том, что если вы знаковое число сдвинули влево так, что старшим разрядом стала 1, то в результате получится отрицательное число. При сдвиге вправо знакового числа, освобождающиеся слева разряды заполняются битом знака (а не нулем), поэтому результат сдвига отрицательного числа так же будет отрицательным (а положительного - положительным:). Если сдвигать вправо беззнаковое число, то свободные биты будут всегда заполнятся нулями.
Кстати, на сколько помню, по стандарту знаковость char не определена (может быть как знаковым так и беззнаковым). Вам с вашим примером не повезло, char оказался знаковым. Зато это дало возможность немного глубже понять сдвиги.

Видимо имеется ввиду бит C (Carry condition flag) регистра CPSR. Обычно по контексту понятно, что имеется ввиду.
Вообще в таких случаях приводите больше контекстной информации, а то вы выдернули кусок кода откуда то, думай что хочешь.

Если статический адрес не вписан в договор с провайдером (или его нет в списке предоставляемых услуг), то скорее всего адрес динамический. Если сейчас он кажется вам статическим, то это не значит, что в один прекрасный день провайдер его не может поменять.
Список диапазонов серых адресов короткий, все диапазоны известны и описаны в RFC, гуглите. Если ваш адрес входит в один из диапазонов - значит он серый (не публичный и не общедоступный).

В батниках все переменные строковые!
set /a для арифметических действий преобразует строки в числа, делает действия и сохраняет строку в результате.
Поэтому дополнение нулями простое: дописываем к числу максимальное необходимое количество нулей, затем убираем лишнее с помощью операции извлечения подстроки.
Для извелечения подстрок читай:
set /?