Wataru

itertools.chain() и itertools.chain.from_iterable()

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

Если бы действительно стояла такая абсурдная задача, то имело бы смысл, чтобы она стала хоть немного реалистичнее, разбить, всё же, всю карту на большие куски и рендерить их отдельно.
Тут есть два подхода:
1) можно качать готовые тайлы и клеить из них тайлы побольше. Есть много источников, многообразие которых можно оценить с помощью ресурса https://nakarte.me/. Это, кстати, opensource-прокт и его исодники доступны на гитхабе.
Качать тайлы можно с помощью проги SAS planetа - www.sasgis.org/sasplaneta
2) Самостоятельно рендерить карты загрузив и отфильтровав дамп БД OSM. Это более сложный путь, но он реализцется на готовых и вплне рабочих компонентах (за исключением абсурдного и нереализуемого требования про рендер в единый файл).

Вы бы подробнее рассказали чего хотите добиться и для чего, а вам бы тут объяснили пределы возможного и целесоообразность разных попыток реалиации этого, а ещё как лучше делать то, что вы в итоге на самом деле хотите.
https://habr.com/ru/post/270513/

Модуль TUN/TAP, через которые работают все не-ядерные VPN, очень медленный из-за того, что у него есть только интерфейс получения и отправки пакетов по одному пакету за вызов. Большое количество переключений контекста между ядром и пользовательским уровнем очень затратны, что влечёт за собой неэффективное использование процессорного времени.

Это типичная известная проблема, которую можно решить в течение месяца, но которую не решили в течение двух десятилетий. Достаточно кому-нибудь взяться, внедрить современный (io_uring, например) или какой-то отдельный интерфейс для отправки и получения нескольких пакетов за один вызов, и скорость магически увеличится на порядок-два.

Оценить ускорение от уменьшения переключений контекста довольно просто, достаточно провести тестирование со значительно увеличенным MTU пакета. Вот какие цифры приводит проект slirp4netns.

Implementation |  MTU=1500  |  MTU=4000  |  MTU=16384  |  MTU=65520
---------------|------------|------------|-------------|------------
slirp4netns    | 1.07 Gbps  | 2.78 Gbps  |  4.55 Gbps  |  9.21 Gbps

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

Исходя именно из этих преимуществ и следует выбирать между функтором и функцией.
Скажем, если бы нужно было nums вписать в CSV таблицу в виде матрицы, то проще использовать функтор. Создать его, настроить поток вывода, символ-разделитель столбцов, количество выводов до перехода на следующую строку и передать в std::for_each.
Если такая настройка поведения не требуется, от функтора лучше отказаться в пользу функции во всех случаях.

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

Что будет?

В данном примере -- то же самое, как если просто написать obj->execute(), т.е. виртуальный вызов конечного переопределения для функции obj1::execute в объекте класса obj3. См. eelis.net/c++draft/expr.call#3

Я не понимаю как это будет работать с классами наследниками и виртуальной функцией.

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

Решето Эратосфена всегда начинается с 2. Его принцип - на каждом шаге находим следующее невычеркнутое число, оно является простым. Для построения массива от 900000000 до 1000000000 необходимо вычеркнуть из этого массива все кратные простым числам от 2 до 500000000, а для этого надо эти простые найти.

return 0;
    menu_for(v);

Казалось бы, что могло бы пойти не так, попробуйте поменять местами return и menu_for

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

Но при этом математика может понадобиться непосредственно для предметной области. В том же геймдеве без нее просто нечего делать.

Дополнительно математика позволяет понимать нормально часть терминов. Например, сложность алгоритмов.

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

Для поиска пути в таком дискретном пространстве стоит обратить внимание на алгоритмы поиска в ширину и в глубину.
Начать стоит с поиска в глубину. Его легко сделать и так же легко понять его неоптимальность. От поиска в глубину довольно легко перейти к поиску в ширину.
Алгоритмы поиска в ширину и в глубину дадут первичное понимание теории построения маршрута.

От поиска в ширину можно перейти к эвристическим алгоритмам поиска: A* или поиску по наилучшему совпадению.
На этом этапе еще полезно познакомиться с алгоритмом JPS. Он может стать даже выгоднее обычного A*.

A* должен стать для тебя основным инструментом поиска в дискретном пространстве. Но у A* есть проблема большой сложности поиска прямого маршрута.
При поиске пути по прямой лучше всего использовать алгоритм Брезенхама.
Этот алгоритм используется для рисования пиксельных примитивов. В частности - прямых.
И суть должна быть в том, чтобы сперва путь искать через Брезенхама по прямой от точки старта до точки финиша, а если Брезенхам наткнется на препятствие, то уже перейти к поиску через A*.

Для очень больших дискретных пространств есть варианты иерархического A*: HPA* и HAA*. Они применяются на иерархических дискретных пространствах вида открытого мира. В освоении они являются самыми сложными и самыми интересными.

А зачем вам вся строка для сортировки?
Вам она нужна только до того байта, который не совпадет с другими строками.
Взять от каждой строки по 64Kб, отранжировать по отличиям в этой части, продолжить читать только у тех, у которых она совпадает. Повторять чтение кусков до прекращения совпадений.

Получается, магическим образом, самопроизвольно, между включениями VulkanTexture.h и VulkanglTFModel.h был объявлен define.

А на самом деле где этот define определяется и как это место относится ко всем этим заголовочным файлам?

Разве препроцессор не последователен и может включать файлы в том порядке, в каком ему заблагорассудится, а не как я написал?

Нет, не может, но возможно ты не вполне понимаешь сам, в каком порядке ты написал их подключение. Так, например, Helpers/VulkanTexture.h и VulkanTexture.h -- это один и тот же файл, или разные? Если один и тот же, то из-за #pragma once в нём он не подключается в VulkanglTFModel.h, а если разные -- то подключается.

Понять, что фактичиски куда подключается можно выполнив вместо шага компиляции только препроцессирование (например, для gcc заменив в команде компиляции ключ -c на -E). В выводе препроцессора не видно дефайнов, но видно когда подключается тот или иной файл и видно весь исходный код не относящийся к препроцессору.

что тут неправильно?

для однозначного ответа на этот вопрос не хватает определения типа Student.
Но судя по тому как всё падает, в Student есть не-POD поля, выделяющие и освобождающие память, например std::string или что-то типа того. Загружать их из файла просто читая записанное ранее содержимое памяти нельзя, потому что загруженные указатели будут ссылаться на невыделенную память, такие типы данных нужно по-честному сериализовывать.

При работе с языками в консоли обычно возникают следующие вопросы.
1) Консоль. Какая кодировка по умолчанию для однобайтных символов. Смотри команду.
chcp для windows или
$ locale для linux.
2) Какая кодировка указана для char для текущего компиллятора. Включен ли режим _UNICIDE.
Посмотри что делают

setLocale(...);
 setCodepage(...);

3) Какой размер символа sizeof(char).
4) В какой кодировке написан исходник. Это можно проверить если посмотреть hex редактором. Там где русская буква может быть например 0xC0 для однобайтной и двух байтной для Unicode.
5) Установлены ли шрифты? Операционка может быть англо-язычной и в этом случае она не обязата что-то специфичное отображать.

const propByPath = (object, path) => path.split('.').reduce((acc, cur) => acc?.[cur], object);