Wataru

Используя Кресты, стоит использовать и их удобства.

std::vector< std::vector< int > > a(rowCount, std::vector< int >(colCount, 0));
void average (std::vector< std::vector< int > > &a){

Так вы не нарветесь на промахи в индексах массива, например. Если умеючи.

А в вашем коде int[][], конечно, не может самопроизвольно превратиться в int*

При попадании в блок:
if (!result)
память реально НЕ выделена и free от неё - это попытка освободить память по адресу NULL. Разумеется, это не будет работать.

upd: Прочитал вопрос ещё раз внимательнее. Надо не забывать делать free в конечном месте использования этого result:

result = get_next_line();<br>
...do_something_with_result...<br>
free(result);

Иначе да, при каждом вызове get_next_line будет выделяться новый блок на 2 байта.

Сделать из teamNames объект, где ключами будут id, а значениями name. Доставать из этого массива имена при переборе epl, используя team_id в качестве ключа.

Собираем новый массив:

const teamNamesObj = Object.fromEntries(teamNames.map(n => [ n.id, n.name ]));
const eplWithNames = epl.map(n => ({ ...n, team_name: teamNamesObj[n.team_id] }));

Обновляем существующий:

epl.forEach(function(n) {
  n.team_name = this[n.team_id];
}, teamNames.reduce((acc, n) => (acc[n.id] = n.name, acc), {}));

В C++ есть getLine, и он читает всю строку:

#include <string>
#include <iostream>

int main()
{
   std::string words;
   
   std::cout << "Введите слова: ";
   std::getline(std::cin, words);
   
   std::cout << "Слова: " << words << "\n";
}

Учите матчасть!
Версия для буфера памяти предполагает, что данные хранятся в непрерывном буфере nm×double (то есть длина mn, элемент double).
Но vector<vector> — он НЕ непрерывный буфер.
Есть непрерывный буфер n×vector<double> — центральный вектор. И каждая из n строчек по отдельности — непрерывный буфер m×double. Относительно друг друга в памяти они могут располагаться как угодно.

Как исправить? — проще всего

double s = 0;
for (i...) {
  s += Sum(m, &a[i][0]);
}

Можно через шаблоны работать, но это уже сложнее и я сам не смогу это с листа написать, что уж говорить про первокура.

Согласно стандарту, дружественная функция может быть определена по месту объявления только для нелокального класса и только если имя функции не является квалифицированным.
Первое ограничение нас мало интересует, а второе - является довольно существенным.

Первично объявленная дружественной функция, согласно стандарту, становится участником пространства имен того типа, для которого объявлена дружественной.
Получаем такую ситуацию. У нас есть пространство имен, пусть даже глобальное, в котором определяется тип. Во время определения этого типа делается первичное объявление функции как дружественной этому типу. В результате этого функция, как бы, объявляется принадлежащей пространству имен в котором определяется тип, но не совсем.

Функция f5 не просто первично объявлена, она и определена по месту объявления дружественности. Ее имя является однозначно неквалифицированным в следствии своего определения.

Еще из стандарта мы можем узнать о том, что первично объявленное дружественное имя не может быть найдено средствами стандартного поиска квалифицированных или неквалифицированных имен.
Именно этот результат мы и можем наблюдать в вопросе. Имя f5 не находится.

Все потому что т.н. имена скрытых друзей могут быть найдены только средствами ADL.
Если коротко, Argument-Dependent Lookup опирается на типы аргументов при вызове функции, пространства их имен и пространства имен, в которых эти типы объявлены.
ADL не выполняет поиск в пространствах имен в отношении фундаментальных типов. Поэтому код f5(5); буквально обречен на ошибку трансляции.

Первично объявленная дружественной функция будет исключительно ADL-доступной до момента своего объявления или определения в том же пространстве имен, в котором определен тип друга. В этом случае функция станет доступна для поиска квалифицированных или неквалифицированных имен.
Для f5 доступен только способ с повторным объявлением, т.к. она уже определена.
Да только в этом случае f5 окончательно потеряет всякий смысл быть дружественной для A и станет просто сильно спрятанной и сбивающей с толку глобальной функцией.
Суть дружественности в раскрытии доступа, которым f5 относительно A не пользуется, т.к. среди ее параметров нет ни одного с типом A.

В результате.
Чтобы ADL нашел функцию f5, среди ее параметров обязан быть параметр и с типом A.
Чтобы UNL или QNL смогли найти функцию f5, ее надо дополнительно объявить за пределами типа A в его пространстве имен.

Типа такого?

В данном коде демонстрируется типичная ошибка подмены типа (type punning [?]), ведущая к неминуемому UB [?] по стандарту.

num в данном случае представляет собой шестнадцатеричное число, при выводе оно переводится в десятичное число типа double.

Вот что стандарт говорит о подмене типа.
[basic.lval#11]

If a program attempts to access the stored value of an object through a glvalue whose type is not similar to one of the following types the behavior is undefined:
(11.1) -- the dynamic type of the object,
(11.2) -- a type that is the signed or unsigned type corresponding to the dynamic type of the object, or
(11.3) -- a char, unsigned char, or std​::​byte type.

Относительно unsigned long long тип double не обладает ни одним из требуемых стандартом свойств. Отсюда прямой вывод что данный код вносит UB.
Поэтому под большим вопросом остается то, что выводится данным кодом.

В итоге, правильным примером подмены типа на другой может быть только пример, где используется подмена на разрешенный тип представления объекта: char, unsigned char или std::byte для C++17.
C++ Core Guidelines в секции C.183 однозначно не советует для подмены использовать union. Этого действительно не стоит делать даже при условии того, что все современные трансляторы понимают такие конструкции так, как подозревает писатель.

Почему неверно работает, к примеру, такой фрагмент кода:

Второй блок кода означает приведение значения из типа unsigned long long в тип double. В этом случае производится именно стандартное преобразование типа, а не подмена с целью интерпретации представления памяти num иным образом.
0xC068C0C000000000 для типа unsigned long long означает 13864543383726325760, при преобразовании этого значения в тип double значение будет преобразовано в 1.3864543383726326e+19. В таком виде оно и будет выведено.

Относительно первого блока кода, лучшим примером подмены типа для кода из вопроса будет такой:

unsigned long long num = 0xC068C0C000000000;
double representation = {};
memcpy( &representation, &num, sizeof( num ) );
cout << representation;

И не стоит бояться обращения к memcpy тут. Данный код полностью соответствует стандарту и ожидаемо оптимизируется транслятором до желаемого результата.

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

Иногда требуется произвести приведение типа значения [?], иногда требуется произвести интерпретацию памяти этого значения другим типом. Это и называется подменой типа или алиасингом. Более детальную информацию о подмене типа, и алиасинге вообще, можно узнать из этой заметки.

Найти k - позицию максимального элемент. Если k < n, то сделать 2 шага: разворот 1...k и разворот 1...n. Теперь максимум точно в конце, и задача свелась к сортировке первых n-1 чисел.

Нормаль к плоскости вычисляется как векторное произведение двух векторов, задающих плоскость. Для точек A, B, C можно взять векторы AB и AC.