Никита

Стандартом определены правила вывода типа для числового литерала из самого литерала. Также в стандарте определен формат представления числового литерала.
Согласно этим правилам и этому формату, 5 будет являться числовым литералом с типом int.
Если бы ты написал 5u, то тип бы уже был unsigned int. А если бы ты написал 5lu, то тип бы уже был unsigned long int.

Вы - ещё одна жертва стремления к немедленной гратификации. Вам не поможет никакой особый проект, потому что изучение языка состоит из довольно монотонного "набивания руки" на решении простых и довольно неинтересных задач. Это проблема не касается программирования, она касается психологии вообще.

10 лет это 3 класс

Отстаньте лучше от ребёнка. Ему всего лишь 10 лет - какое программирование? Пусть он сначала насладится детством. А уже после - сам начнёт ковыряться в том, что ему понравится

включил оптимизацию, время добавления элементов сравнялось, потребление памяти упало на обоих до 176 МБ

Размер не соответствует расчётному из-за того что аллокации через new происходит не плотно. Между разными нодами есть память, которая выделена процессу, но не занята полезными данными.

Можно подсчитать размер потерянной в пустую памяти кодом (для x86):

std::vector<uint32_t> ptrs;
ptrs.reserve(list.size);
for (auto node = list.head; node != nullptr; node = node->nextNode) {
    ptrs.push_back((uint32_t)node);
}

std::sort(ptrs.begin(), ptrs.end());

uint32_t wastedSpace = 0;
for (uint32_t i = 1; i < ptrs.size(); i++) {
    wastedSpace += ptrs[i] - ptrs[i - 1] - sizeof(D1List<int>::Node);
}

В Debug, forward_list работает медленнее потому что внутри у него много вызовов функций. В Release они оптимизируются и инлайнятся.
Скорее всего, памяти в Debug используется больше для анализа утечек памяти.

Очевидно что это ссылка на указатель.
Ссылка позволяет менять значение переменной вне вызываемой функции. Укатаель, который вы передадите первым параметром функции, будет изменен на newArray.

Потому что JS-обезьяны, которые даже TS не знают, делают на своём JSе неподдерживаемое, но рабочее говно за месяц, а ты на своём фортепиано делаешь тоже самое за год.

В бы рекомендовал начать в такой последовательности:

The C++ Programming Language — Bjarne Stroustrup
C++ for Real Programmer — Jeff Alger
The Art of C++ — Herbert Schildt
Algorithms in C++ — Robert Sedgewick
Design Patterns: Elements of Reusable Object-Oriented Software — Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
C++ Gotchas. Aoiding Common Problems in Coding and Design — Stephen C. Dewhurst
C++ Templates: The Complete Guide — David Vandevoorde, Nicolai M. Josuttis
The CERT C Secure Coding Standard — Robert C. Seacord
More Effective C++: 35 New Ways to Improve Your Programs and Designs — Scott Meyers
Effective C++: 55 Specific Ways to Improve Your Programs and Designs — Scott Meyers
C++ Coding Standards — Herb Sutter, Andrei Alexandrescu
C++ Concurrency in Action: Practical Multithreading — Anthony Williams
Ну и со временем начать мониторить станадрат )

PS: на сколько я помню, в некоторых книгах есть неточности и опечатки, так что будьте внимательны и начинайте именно с первой.

Замени head = malloc(sizeof(struct Node)) на head = new Node.
Потому что malloc тебе конструктор std::string внутри data_list не вызовет.
И не вставляй код картинками.

У вас каша в голове, связанная с отсутствием опыта решения задач.

1. Ваш первый пункт вытекает из второго. Если вы умеете п. 2, то и п. 1 вы сможете научиться (быстро). Уметь только в CMS это примерно как уметь забивать гвозди только одного вида (а ведь могут потребоваться и другие гвозди).
2. Вам нужно понимать, что есть задача, а есть инструмент. Все что вы перечисляете - это инструменты для решения задач. Какие инструменты изучать? Инструменты, которые подходят под задачи, которые вы решаете. Какие задачи вы решаете или хотите решать? Это основной вопрос.
3. Не стоит обращать внимания на длительность уроков. Никто не начинает работать только после того, как просидит N часов за теорией и N часов за практикой. Осваиваете базу, начинаете что-то делать на реальных задачах и постепенно учитесь (не в ущерб времени и деньгам клиента конечно же).
4. Этот пункт - продолжение третьего. Вы смотрели что такое jQuery? Вы пытались им пользоваться? Зная js, приучить себя к jquery можно за 3-4 проекта. Надо просто брать и делать, а не думать: "там по jquery уроков на 300 часов, видимо это слишком сложно для меня". Вам нужно брать и начинать.
5. Задачи всегда бывают разные, следовательно и подбор инструментов тоже, следовательно нужно знать и jQuery и Vue.js, а не что-то одно. Не всегда же вы пилить SPA будете? Кому-то потребуется сделать простой калькулятор, чтобы человек мог его поправить потом. Будете использовать Vue, который клиент может не знать? Или все же jQuery или нативный js? Ответ очевиден.

Опишу свою ситуацию:
1. Начинал с HTML + CSS
2. Начал учить JS и параллельно Jquery (никогда так не делайте, сначала js, потом jq).
3. При набранном опыте я смог нормально освоить Vue за 1 проект (объемный).
4. Так как иногда роюсь в PHP, освоиться в Laravel на уровне: есть проблема - знаю где посмотреть и как ее решить в случае чего, смог за 1 проект длиною в месяц.

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

Поэтому вам нужно:
1. Определиться с выбором области работы, судя по вашему вопросу у вас выбор между фронтом (javascript + frameworks) и беком (python, php + frameworks)
2. Далее загуглить road map по фронту или бекенду (в зависимости от вашего выбора)
3. Поступательно двигаться и не бояться.
4. У вас еще хватит времени прожить счастливую и долгую жизнь.

P.S вся эта арифметика со скоростью изучения фреймворком исключительно мой опыт, у кого-то быстрее, у кого-то медленнее. Дабы внести разъяснения, добавлю: я вполне себя спокойно ощущаю в том или ином фреймворке, однако не являюсь очень серьезным разработчиком.

P.S.S Отвечая на главный вопрос: "Какие области в веб — разработке осваивать в перспективе?" - в перспективе нужно становиться разработчиком, у которого есть достаточно опыта в смежных областях, есть знания, помогающие решать те или иные задачи (чем сложнее задачи, тем больше ваша зп, тем вы ценнее), и постоянное развитие, так как наука продвигается, задачи и их сложность меняется, инструменты добавляются и так далее. И не забывайте, программирование это не только делать сайты или приложения, если области задач, не связанные с веб разработкой, но которые тоже интересны.