Wataru

Верно. Можно вставить исходник на сайте C++ insights и посмотреть, какие типы там где используются.

Смотрите документацию. Там действительно утверждается, что int32_t должен иметь размер ровно 32 бита ("exactly").

Где вы взяли, что int32_t - это псевдоним int?
Подозреваю, что там, где вы это видели, куча #ifdef и проверок архитектуры.
Возмножно, на вашей системе, где int итак имеет 32 бита так оно и есть. При компиляции на другую архитектуру внезапно может оказаться, что int32_t - нифига не псевдоним к int.

Берете 2 любве точки, пересекаете окружности. 2 получившиеся точки проверяете с остальными n-2 окружностями.

Выводить в фиксированном виде:

std::cout << std::fixed;  // Меняем формат вывода вещественных чисел 
std::cout.precision(10);  // Сколько вы там хотите знаков после запятой выводить.
double e = 1.3333e6;
std::cout << e;  // 1333300.00000000000;

Случай, когда у вас динамически добавляются новые строки, но все они фиксированной длины - редок. Да и в этом случае можно завести vector из array'ов. Ничего городить нового, тем более в стандартах, не надо.

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

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

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

Просто догадки:
У вас опечатка - функция mian вместо main.
Потом, в конце функции должно стоять return 0;

Когда вам важен порядок операций в разных потоках их надо синхронизировать по-другому. Атомарые операции тут точно не помогут. Нужны события. Один поток должен ожидать события, второй - сигнализировать его.

В стандартной библиотеке самое близкое к этом - std::condition_variable.

Платформо зависимое решение может быть эффективнее. Какие-нибудь WaitForSingleObject/CreateEvent в винде, например.

Я так понимаю, речь о винде?
Вот статья.

Рекомендуется использовать Clipboard Format Listener. Надо будет вызвать AddClipboardFormatListener и потом обрабатывать сообщение WM_CLIPBOARDUPDATE. Гуглите эти слова (+ example), и найдете кучу готовых примеров в интернете.

Любой нормальный редактор Через функцию find-replace all заменит сколько угодно строк в файле. Даже чертов notepad.exe справляется без проблем! Чем вы там вообще пользуетесь?
Может вы там пытаетесь сначала список всех изменений посмотреть? Тогда может быть редактору плохеет все изменения показывать. Но какая-нибудь кнопочка replace all должна отработать без проблем.ы

Чтобы в коде это все можно было менять быстро, заведите переменную, которую везде подставляйте вместо 1*multiplier. А вообще, похоже, что этот код уже сделан гибким - просто измените значение multiplier.

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

Но если вам по заданию надо бинпоиск использовать, то у вас там следующие ошибки в реализации:
- постоянное преобразование к toLowerCase - это ОЧЕНЬ неэффективно. Один раз все приведите к lowerCase и работайте только с этим. Можно эти ключи схоранить в новых полях.
- когда вы нашли совпадение, можно делать из цикла break.

Вы не сможете бинпоиском найти все объекты. Он может найти только один. Самый левый, самый правый, или как повезет - зависит от реализации.
Вам надо запустить два бинпоиска последовательно. Один будет искать минимальный элемент, больше равный искомому (lower_bound), а второй бинпоиск будет искать максимальный элемент строго больший искомому (upper_bound). Пусть ваши бинпоиски возвращают индекс в массиве list. Эти две функции будут отличаться только в одном месте - там будет < и <= соответсственно.
Ответ к задаче будет в массиве list по индексам от lower_bound (включительно) до upper_bound (не включительно). Может быть и так, что lower_bound == upper_bound, если искомого элемента в массиве нет и ответ будет пустым.

Это все ссылки. Вершина хранит ссылки на ребра, ребра хранят ссылки на вершины. Поэтому эта вложенность не страшна. Она - головная боль сборщика мусора (так называется часть менеджера памяти, которая освобождает ненужную больше память).

Я бы действительно не вводил сущность ребро. И просто в вершинах хранил список соседних вершин (оно еще называется список смежности). Так экономнее, быстрее и проще.

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

pd.options.display.max_rows = 1000 перед выводом.