Евгений Шатунов

У операции разыменования приоритет ниже, чем у операции выбора элемента по указателю, т.е. в вызове *root->next.push_back(node); порядок операций такой *(root->)next.push_back(node);, что, видимо, не то что вы хотели, расставьте скобки так: (*root)->next.push_back(node); и будет счастье.
А вообще, какой смысл в On_BG передавать указатель на указатель? Судя по коду достаточно просто указателя, а еще лучше - ссылки.

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

Правилом хорошего тона считается постановка фигурных скобок в любом случае. Для вдохновения можете прочитать вот эту статью: Исключительная красота исходного кода Doom 3

Такие дельные советы тут...

А правило проще некуда: если вы без указания типа и так УЖЕ ИМЕЕТЕ достаточно информации, чтобы уверенно работать со значением - тогда можно использовать auto. Если чувствуете, что не имеете, или сомневаетесь, что имеете - лучше тип указать. Пример, где использование auto отлично подходит - итераторы:

std::list<int> items;
auto i = items.cbegin();

Во второй строке четко написано - items.cbegin - константный итератор по items, бегущий с начала списка. Мне этого более чем достаточно. Указание типа std::list<int>::const_iterator мне никакой новой информации не принесет. Тем более, т.к. итераторы от разных контейнеров несовместимы, то мне нужно еще и сразу знать, по какому конкретно списку у меня итератор - я опять-таки посмотрю на items.cbegin, а не на тип.

А вот auto в объявлениях функций/методов и правда ни к чему. Его, кстати, даже не сразу там разрешили использовать (только в C++14). Причина тому вновь читабельность - чтобы понять, что возращает функция, нужно прочесть ее текст как минимум до первого return, а лучше - полностью. Единственный сценарий, где без auto не обойтись при указании возвращаемого типа - это стрелочная нотация с decltype, но я думаю вы не скоро с ней столкнетесь.

[x - y for x, y in zip(b, a)]

> ссылок на ссылки
Это не ссылка на ссылку. В функцию b попадет точно такая же ссылка, что и в f. Ссылки ведут себя как "вторые имена" для переменных, поэтому когда вы инициализируете одну ссылку другой, вы просто добавляете в распоряжение еще одно имя для куска памяти. Такого понятия, как ссылка на ссылку в принципе быть не может, в отличие от "указатель на указатель", т.к. указатель сам по себе - реальная самостоятельная переменная с выделенной для нее памятью, на которую, в свою очередь, также можно получить указатель. Ссылка - это запись в таблице идентификаторов компилятора. Да, в зависимости от ситуации для обеспечения ее работы может потребоваться указатель (например, при передаче ссылки в функцию нужно как-то передавать адрес), но этим уже занимается компилятор, поддерживая для вас абстракцию ссылки.
Другое дело - это, как указал Александр Ручкин - время жизни объекта, это другая история. Разумеется, тот объект или значение, ссылку на который мы сформировали, должны "жить", пока к этому объекту идут какие-либо обращения на чтение/запись.
UPD: Кстати, int&& - это НЕ ссылка на ссылку, это r-value ссылка и совсем другая история.

навсегда до момента пока кто-то не решил что вы нарушаете чьи-то права. потом навсегда заканчивается =)

Во-первых, new char выделит память только для одного символа, а у вас их много. То есть уже в следующей строке (cin >> array) проезд по памяти. Если пишете в целях обучения и нельзя брать std::string, то выделяйте с запасом, например new char[256]; Освобождать при этом память надо будет при помощи delete[] array;
Во-вторых, конец строки определяется по нулевому символу на конце. cin >> array делает это сам (пишет в конец array нулевой символ), а вы в своей функции нулевой символ не выставляете. Сделать это можно так:
str[length_str] = '\0';
Но надо иметь в виду, что памяти надо выделить [хотя бы] на 1 больше, чем length_str.

Итого:
1. Вам надо в обоих случаях память выделять под массив. В первом случае можно под 256 элементов. В идеале при этом читать не при помощи cin, а другими функциями, дабы избежать переполнения на случай, если введут строку более длинную.
2. В reverse надо выставлять терминирующий нуль и исправить длину массива. Возможно вообще разворачивать строку по месту, т.е. менять местами буквы, а не создавать новую строку (в этом случае не надо ни память выделять, ни трогать терминирующий нуль, он останется на месте).
3. Вам надо удалять выделенную память по окончании использования при помощи delete []