res2001

Расстояние, думаю, все таки должно быть разностью, а не суммой.
Сделайте отдельный цикл для суммы от 0 до size-1.
И отдельный цикл для min/max от 1 до size-2. Перед началом цикла min = max = rast[0] + rast[1]. Ну и size должен быть > 2.
else{} лишнее, не нужно засорять код. И так все очевидно.

Отправляйте по UDP и не парьтесь с ответами - это же не критически важный функционал - дойдет, хорошо, сервер учтет, не дойдет - пофигу.

Просто при каждом вызове с помощью набора арифметических операций генерируют очередное псевдослучайное число. Важно не забывать инициализировать генератор с помощью вызова srand().

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

Даже странно такое сравнение. Если требуется эффективность, то Си/С++ без вариантов.
Насчет ног - не так страшен черт. Пишите тесты, будьте внимательны с указателями и все получится.

По исходникам любая IDE в своем менеджере проектов умеет показывать дерево объектов, функций, типов. Та же студия, например.

Вместо HTTP GET ..., шлете, например двоичную 1 - в первом байте пакета, пришлете в первом байте 2 - POST. Принимающая сторона, принимает не текст, а двоичные данные, анализирует сначала полученный первый байт, и дальше разворачивает остальные данные. Если что, пример не из жизни, придуман на ходу.
В принципе разница с текстовыми протоколами не велика. Но бинарные протоколы гораздо компактней. Кроме того не нужно парсить полученный текст, из-за чего обработка пакетов, обычно, проще.
Но, конечно, если снифер не знает протокола, то в перехваченных данных трудно будет разобраться без подготовленного инструментария. А кроме того сценарные ЯП, которые распространены в вебе, как правило с двоичными данными работают через жо...

Видимо вы имеете ввиду происходит ли фактическое освобождение памяти на уровне операционной системы при вызове delete и free?
Не обязательно. В стандартной библиотеке есть свой менеджер памяти интерфейсом к которому являются new/delete/malloc/free. У этого менеджера памяти какой-то свой алгоритм работы и он не обязательно при каждом вызове запрашивает/возвращает память ОС. На сколько я знаю в стандарте никак не регламентируется этот вопрос, поэтому поведение менеджера памяти - целиком на совести разработчика стандартной библиотеки для вашего компилятора.
Более того стандартный менеджер памяти можно заменить другим, они есть уже готовые. Можете написать свой собственный, такой как вам нужно.
Если вы хотите построить на поведении стандартного менеджера памяти какую-то логику приложения, то не стоит этого делать, т.к. в следующей версии вашего компилятора реализация менеджера памяти может быть другая.
Вообще не нужно приписывать дополнительный функционал стандартной библиотеке. Воспринимайте все что написано в стандарте буквально и ничего от себя не добавляйте.

А вы документации не доверяете что ли?
Забивает память нулями только calloc, о чем в доке написано.
Проверено неоднократно.
Чтоб проверить выделите массив intов, например побольше - несколько мегабайт, и ищите в нем не нулевые значения. Уверен, долго искать не придется.

Само решение задачи оптимизировать бесполезно, т.к. тут на столько все просто, что любые оптимизации дадут прирост в 1-2 процессорных инструкции, а это в любом случае будет меньше 1 млсек.
Попробуйте исполнить ваш тест несколько раз и вычислить среднее время, если это возможно.
Или вставьте в свою программу вычисление времени выполнения и больше не беспокойтесь по этому поводу: www.cplusplus.com/reference/ctime/clock/?kw=clock

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

С/С++ не выйдут из моды еще долго, у них своя область применения и там они практически вне конкуренции.
MFC - не стоит тратить на нее время. Она уже 20 лет назад была похожа на неповоротливого монстра, не думаю, что с тех пор что-то изменилось в лучшую сторону. К тому же привязка к одной платформе и одному компилятору, в наше время - это большой минус. И, кстати, на сколько я знаю, в бесплатных версиях VS MFC нет.

1.обычно у каждого компилятора свой runtime. Для VC - это разные версии msvcrt.dll.
2.Читайте на сайте разработчика компилятора. В основном это не сильно принципиально, разве что вы используете какие-то специфические плюшки, которые не описаны в стандарте, но есть в конкретном компиляторе и его стандартной библиотеке.
3.runtime - это как правило стандартная библиотека + точка входа и завершения программы (а ваш main вызывается уже из runtime).
4.Можно. Обычно стандартная библиотека поставляется как в виде динамической библиотеки, так и статической. Выбор какую использовать за вами, задается опциями компилятора.
5.Не большой. Но тут лучше говорить не про оверхед, а про "написание программы на чистом" WinAPI/POSIX и других OS API. На сколько это трудозатратней по сравнению с использованием стандартной библиотеки.
По собственному опыту скажу, что написание на чистом WinAPI довольно трудозатратное (и время затратное) занятие, затратнее примерно в 1.5 по сравнению использованием stdlib. Но у меня это был первый и пока единственный опыт, дальше, видимо должно быть проще.

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

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

Возможно setjmp/longjmp это то что вам нужно?

Вы в тегах ставите Visual Studio, а компилируете gcc?
Видимо, вы пытаетесь собрать свой хеловорд с помощью mingw?
Тогда запустите сначала оболочку mingw - она обычно запускается стартовыми скриптами: "MinGW-w64 Win64 Shell" и такой же для x32 версии.
Оттуда и компилируйте, а не из командной строки винды.