res2001

Не нужно ставить микротик у провайдера, купите в головной офис статический белый адрес и микротик поставьте у себя. Впрочем даже микротик не нужен, зависит от того где вы сейчас осуществляете маршрутизацию филиалов, возможно, ВПН можно поднять там же, это было бы удобно.
Кстати, я бы и филиалы, которые работают по VLAN оператора завернул бы в ВПН - так безопасней. Хоть трафик и не гуляет по интернету, но его видит оператор. Нужно ли это бизнесу?

Нужно делать цикл по исключаемым файлам и исключать файлы по одному.
В make для этого есть $(foreach ...)

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).