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

С чего вы взяли, что внутри шаблона это работет? Вы его инстанциировать пробовали (объявить переменную класса Outer<int>, например)?

Вылезает точно такая же ошибка.

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

Вам повезло. Какой-то из включаемых вами других хедеров уже включает cstdint. Поскольку система инклудов в C++ идет еще из C и это дикое и неудобное легаси (текст хедера тупо вставляется в файл вместо include препроцессором), то такое рекурсивное включение работает.

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

Такая запись имени типа в скобках в выражении - это явное приведение типа. Тут вы указываете компилятору, что выражение надо преобразовать вот к такому вот типу (флоат, в данном случае).

float нужен вам в начале, потому что вещественные константы имеют тип double. Поэтому у eps/2.0 и 1.0 в первом цикле имеют тип double, все вычесляется в double. Преобразовав одно из выражений в float вы получаете то, что вам надо. Без этого все вычисления идут в double и ответ находится не тот. На самом деле там float при сравнении все-равно расширяется до double но на результат сравнения это не влияет в данном случае.

Еще, вместо явного приведения типов, можно поставить f после вещественных констант, чтобы указать компилятору, что это float:
while (1 + eps/2.0f != 1.0f){

Тогда вычисления будут во float и ответ будет правильный.

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

Можно через vector::reserve задать ему необходимый объем. Тогда он сразу же выделит все память и, если вы не будете в него класть больше этого размера элементы, он не будет перевыделять память вообще.

Еще можно изменить ваш дизайн. Например, вместо vector использовать list, итераторы в котором не портятся от добавления. Или хранить вместо итераторов/указателей на элементы в векторе индексы.

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

Разбейте задачу на подзадачи:

1) Проверить, что данный элемент надо удалить
1.1) Проверить, что элемент не уникальный
1.2) Проверить, что элемент - не первый среди одинаковых (один-то его надо оставить)
2) Удалить элемент из массива дописав 0 в конце.

Все эти пункты выполняются циклом. в первых пунктах будет удобно завести булевую переменную, которая после цикла будет содержать значение проверки.

Если без велосипедов, это https://en.cppreference.com/w/cpp/algorithm/ranges...

Проблема вот тут:

parent.resize(++n);
glub.resize(n);
for (int i = 1; i <= n; i++) {

Выход за границу массива. Неопределенное поведение.
Вы выделяете массивы длины n (увеличенного на 1) и потом проходитесь от 1 до n (увеличенного на 1). Но ведь индексы в массиве только до n-1.

Правильно так:

parent.resize(n+1);
glub.resize(n+1);
for (int i = 1; i <= n; i++) {

value тоже должна быть constexpr

Без constexpr срабатывает как раз VLA, о котором пишет Александр Ананьев

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

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

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

Чтобы поменять два значения местами, надо сначала одно значение переложить в какую-то временную перменную. Вот тут и вызывается конструктор.

void swap(T &a, T &b) {
  T tmp{std::move(a)};
  a = std::move(b);
  b = std::move(tmp);
}

Проблема вот в этой строчке:
return str.c_str();

Тут вы возвращаете указатель на внутренние данные у str. Но при выходе из функуции str уничтожается - это же локальная переменная. В итоге у вас получается висячий указатель (указатель на память, которой вы уже не владеете). Эту память какая-то другая часть вашей программы переиспользует и там остается что-то не ваше, выглядещее для вас, как мусор.

Вообще, это undefined behavior - доступ к висячему указателю. Программа вполне может и аварийно завершится.

Для решения этой проблемы возвращайте std::string. Или выделяйте char* вручную, через new[] (только не забудьте указатель потом удалить в вызывающем коде). Но лучше, конечно, возвращать string и не мучатся с ручным управлением указателями.

Эти три функции идентичны, с точностью до переименования локальных переменных. Вы три раза написали одно и тоже. Можно 2 функции просто удалить и использовать отсавшуюся три раза.

Ну какая разница, как у вас там переменная называется sA или sB - результат будет один и тот же.

Да, может вы путаетесь, но аргумент в функции можно тоже переменовать. Хоть там и написано int masivA(int* a), этот a - это аргумент. Он никак не привязан к массиву a в main(). Туда можно передать и a и b и любой другой массив.

Это получается не переопределение, а просто метод у другого типа с таким же названием. Изначальный метод все еще можно вызвать у объекта класса (если привести тип). Также изначальный меотд доступен внутри класса потомка.

Суть переопределения в том, что это ПЕРЕопределение. Замена одной функциональности на другую. Без virtual этого не происходит.

Можно же объявить функцию fn у двух совсем не связанных классов, вызвать ее у двух экземпляров и увидеть разный результат, правда? Но тут нет никакого переопределения. Концептуально у вас тут то же самое.