res2001

Ваши примеры работы с указателями не сильно интересны - вы рассматриваете только 2 простейшие операции, причем 4 и последующие примеры явно искусственные, в реальности вы вряд ли такое встретите.

Рассмотрите лучше работу с массивами через указатели.
Сначала одномерные массивы, потом перейдите к двумерным и трехмерным. Заодно поймете работу адресной арифметики.
Так же стоит освоить передачу одномерных и n-мерных массивов как параметры в функции, это то же часто вызывает вопросы.
Еще интересный вариант - массив массивов (это типа двумерного массива, только организуется как массив указателей).
Еще есть интересные варианты использования указателей из области драйверописания - типа нескольких вариантов записи/чтения области памяти адрес которой известен. Придумайте 2-3 варианта. Но это довольно просто, на практике хватает одного варианта :-) но знать альтернативы, как минимум не плохо.
Так же освойте работу с константными указателями, указателями на константу и константными указателями на константу.

Начинайте уже писать.

assert в драйвере - это как-то перебор.
Просто обнуляйте младший бит принудительно и будет у вас всегда четное число.
А в инструкции опишите, что значение приводится к ближайшему меньшему четному.
Для 1 байтового значения это будет так:
val & 0xfe

Указатель this? В Си классов нет, вам нужно избавится от классов.
Класс переделывайте по следующей схеме:
1.все члены данных класса переходят в аналогичную структуру на Си как есть.
2.все методы класса реализуются в виде обычных функций, первым параметром в функции передавайте структуру из п.1, можете указатель на структуру назвать this, тогда в коде функции не придется this заменять на что-либо другое.

Вообще свободные реализации БПФ есть, на вскидку: fftw и fftpack.
fftpack - на фортране.

В свое время пользовался вот такой реализацией. Это стандартное комплексное БПФ. Собирается без проблем (math.h, конечно должен у вас работать или сами реализовывайте sin и cos). Правда там используются 2 разных массива для действительной и мнимой части, тогда как сейчас используют структуру для представления комплексных чисел. Но это, я думаю, легко поправить.
И на счет ваших проблем с math.h не очень ясно. Думаю в любом случае нужно с ними разобраться.

Расстояние, думаю, все таки должно быть разностью, а не суммой.
Сделайте отдельный цикл для суммы от 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