res2001

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

int next_edge(edge_t **out_edge)
{
  edge_t * tmp = malloc(sizeof(edge_t));
  if(tmp)
  {
     *out_edge = tmp;
     return 1;
  }
  return 0;
}

Но обычно проще в таком случае возвращать указатель в возвращаемом значении. Вызывающий код может сравнить возвращенное значение с NULL для выяснения того вернула функция нормальный указатель или произошла ошибка. Так делает, например, функция malloc().

Что касается ImageMemoryCache: в методе get вы возвращаете ссылку на элемент мапы. Блокировка с мапы снимается при выходе из get, но вызывающий код имеет ссылку и может с этим объектом делать все что угодно.
Параллельно вы можете вызвать clear, который удалит элемент на который осталась ссылка в другом потоке.

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

У меня был некоторый опыт с uboot, правда для другой ОС

Если у вас какая-то стандартная покупная плата, то возможно в uboot уже есть готовый config. Обычно производители плат в документации указывают как собрать uboot под их плату (если они поддерживают uboot), либо это можно нагуглить в интернете.
Если же плата самодельная, то берете самый близкий для вашей платы config (вы же брали за основу какой-то референс дизайн платы, вот эту плату и берите за основу), переименовываете его и вносите в него соответствующие изменения.
Бывает, что вместе с config'ом требуется вносить изменения и в dts, они в uboot лежат в ./arch/<platform name>/dts. Название используемых dts лежит в переменной CONFIG_DEFAULT_DEVICE_TREE и/или в CONFIG_OF_LIST в config файле.

Config файл - это просто набор параметров, которые превращаются в набор инструкций #define при сборке.
С dts все сложнее. Там целый язык описания железа.

Для сборки uboot рекомендую следующую последовательность:
1. Заведите для сборки отдельный пустой каталог. Он будет текущим каталогом для всех дальнейших команд
2. Пусть каталог где лежит сам uboot хранится в переменной UBOOT_DIR. Архитектура процессора вашей платы (например arm) в переменной ARCH. Префикс для кросскомпилятора в CROSS (например arm-linux-gnueabihf-). Имя выбранного defconfig файла в переменной DEFCONFIG (имя указываете вместе с суффиксом _defconfig)
3. Очистка каталога сборки:

make -C $UBOOT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS distclean

Эта команда пригодится при пересборках в случае изменения конфигурации
4. Подготовка конфигурации для сборки:

make -C $UBOOT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS $DEFCONFIG

5. Сборка: make -C $UBOOT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS

Несколько полезняшек:
1. Вы можете задавать дополнительную опцию для make: -O <путь>
Она задает каталог, в котором будет происходить сборка. Этот каталог make создаст сама. Это бывает удобно, если работаете сразу с несколькими конфигами.
2. В uboot встроен конфигуратор конфигов :) Конфигурация происходит в текстовом режиме с помощью меню, присутствуют подсказки для опций и т.п. Когда вы создали начальную конфигурацию в п.4 выдайте команду:

make -C $UBOOT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS menuconfig

Тут то же можно добавлять опцию -O для выбора каталога с конфигурацией. После исправления конфигурации, не забудьте ее сохранить.
Дальше нужно дать команду:

make -C $UBOOT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS savedefconfig

Она создаст на основе текущей конфигурации defconfig файл в каталоге сборки. Этот файл можно переименовать в <имя платы>_defconfig и подложить в каталог с конфигами uboot и в дальнейшем использоавть его для сборки.
3. В каталоге с uboot дайте комаду make help для получения списка возможных опций.
4. Обычно я собираю uboot под линукс, но та же схема вполне работает и в WSL под виндой. Набор кросс-компиляторов есть в портах (в WSL исопльзовал дистрибутив ubuntu).

Желаю удачи!

При чем тут cmd/bat?
Делайте бэкапы, и восстанавливайте файлы из бэкапов.
Обычно чем вы создаете бэкапы, тем же инструментом и восстанавливаете.
Инструментов для бэкапа/восстановления много. В т.ч. можно накропать соответствующие скрипты и на батниках, используя какой-нибудь архиватор.

Если вы надеялись на простой чудесный способ восстановления без предварительного бэкапа, то такого варианта не существует.

Смотри сначала сюда: https://en.cppreference.com/w/cpp/io/basic_fstream
Потом сюда: https://en.cppreference.com/w/cpp/io/basic_filebuf/open
fstream открывает файл по умолчанию (как у тебя) в режиме in|out, а это значит, что если файла не существует, то возникает ошибка (смотри таблицу по второй ссылке). Логика такая, что если ты открываешь файл для чтения (тут не важно, что он открывается еще и для записи) без дополнительных флагов, то файл должен существовать.

В пару с ifstream, который открывает файл для чтения, существует и ofstream - он открывает файл для записи. При использовании ofstream не существующий файл будет создан (смотри таблицу по второй ссылке).

schtasks /?

Напишите команду start сразу после do.
Или можно завернуть start в круглые скобки. Открывающая круглая скобка должна быть после do в той же строке.
Т.е. for вместе с телом цикла - это одна команда для cmd и она должна быть на одной строке. Круглые скобки позволяют обойти это ограничение.

Я предполагаю, что в папку с приложением нужно разместить библиотеки c++.

Да вы верно думаете. Но делать надо не так.
Ошибка возникает потому, что в С++ вы, как правило, используете хотя бы STL - а это внешняя библиотека и она должна быть доступна программе во время запуска.
Но можно собрать программу со статической линковкой с STL, тогда размер исполняемого файла вашей программы будет больше, но тащить за собой ничего не придется.
В принципе, динамическая линковка с STL - это нормально. Только в случае с программой собранной в MSVC вы должны предоставить пользователю еще и runtime пакет нужной версиии. Микрософт предоставляет эти сборки runtime отдельно от MSVC (можно скачать с сайта). Этот же установщик рантайма лежит где-то в недрах установленной MSVC, можно его там найти при желании.

Цифры в имени файла dll (140) - это и есть версия нужного вам рантайма. Версия 140 или 14.0. Она идет с MSVS 2015.
Вот тут статья с перечислением всех актуальных версий рантайма и ссылками на них: https://www.itechtics.com/microsoft-visual-c-redis...

Это потому что вы компилируете с помощью gcc.
Вообще в стандарте С++ VLA (variable length array) нет в принципе и это ошибка.
Но VLA есть в C99 и далее. А gcc с параметрами по умолчанию разрешает использовать расширения, в т.ч. и VLA.
Стоит включить более строгое соответствие стандарту, как вы получите ошибку и не собираемый код.

Рекомендую это (включать строгое соответствие стандарту) делать в своих проектах всегда. А так же включать вывод всех предупреждений (-Wall -Wextra) и пытаться добиваться сборки без предупреждений.
Наиболее "продвинутые" переводят все предупреждения в ошибки, что бы программа в принципе не собиралась с любыми предупреждениями. Это то же делается соответствующей опцией компилятора.
Часто в таких случаях приходится некоторые предупреждения ставить в игнор, но это делается всегда осознанно, с пониманием для чего это нужно.