Wataru

Суть проста: У вас есть два набора из N чисел. Две строки чисел одинаковой длины, если хотите. Надо в каждом столбце (из двух элементов) наверх поставить максимальный, а вниз - минимальный.

Для решения этой задачи надо уметь в массивы, циклы, условные операторы и уметь поменять местами два значения. Код тривиален: пройдитесь циклом от 0 до N-1 (ведь нумерация с 0) и, если элементы в заданном столбце идут не в том порядке, в каком должны, поменяйте их местами.

Код напишите сами. Хотя бы попробуйте.

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

Но тут ситуация другая. Майкрософт что-то намудрили cо стандартами и названиями. Чую тут какую-то долгую и запутанную историю полную костылей и заплаток. Я так понял, что _kbhit, это winapi функция, а kbhit - это сишная функция в стандартной библиотеке. Вторая просто вызывает первую. Но нельзя было сделать две функции с одинаковыми названиями, поэтому эти winapi-шные функции оставили с _ в названии.

Уловка в системе процессорных комманд: 48 c7 45 08 - позволяет загрузить в 64-битную ячейку памяти 32 битное число, автоматически расширяя его до 64 бит.

Смотрите список кодов x64:
0x48 - означает, что следующая комманда работает с 64-битами.
0xC7 - mov immediate (данные в команде)
Дальше идут флаги, указывающие как интерпретировать аргументы, что куда адресовывать и т.д.

Но важно, что команда C7 работает с r/m16/32/64 данными, а аргумент у нее может быть только imm16/32 (третий столбец). Т.е. она принимает или 2 или 4 байта, в зависимости от обвеса, а записывать может до 64 бит. Сравните это с коммандой 0xB8 в той же таблице, она уже может принимать 64 бита.

Если аргумент меньше ячейки памяти, то он расширяется (sign extended) до нужного размера (бит знака копируется влево до упора). Это позволяет записать числено равное значение в более битную ячейку. ведь 32-битное число 0xFFFFFFFF - это -1 в дополнительном бинарном коде, а 0xFFFFFFFFFFFFFFFF - это тоже -1 в дополнительном 64-битном коде.

Компилятор использует вот эту команду, а не 0xB8, потому что сама команда короче, а исполняется так же быстро. Меньше кода, больше всего помещается в кеш и все работает быстрее, да и exe-шник меньше получается.

Верно. Можно вставить исходник на сайте 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, если искомого элемента в массиве нет и ответ будет пустым.

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

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

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