Dmitrii

{
  thread gameThread(game_loop, ref(star_pleced), ref(staircase_placed), ref(c), ref(t_placed), ref(r_placed), ref(p_placed), rows, cols, ref(map));
  thread monsterThread(monster_move, ref(map));
  gameThread.join();
  monsterThread.join();
  refresh();
} while ((c = getch()) != '0');

Этот код запускает потоки (они один раз исполняются) потом ждет их завершения. И это в цикле.
Проблема в том, что на каждой итерации этого цикла вы будете ждать, пока monster thread спит.

Потоки тут вообще бесполезны, вы с тем же успехом можете просто вызвать функции напрямую.

Потоки должны быть запущены один раз и работать в фоне. Тот, который каждую секунду что-то делает, должен внутри содержать цикл и работать бесконечно, на каждой итерации засыпать на 1 секунду.

Вы случайным образом генерируете координаты комнаты в цикле, пока вам не повезет выбрать полностью пустое место (while (collision == true);).

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

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

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

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

Практический совет - лучше писать через индексы, ибо так понятнее и больше шансов что компилятор там все наоптимизирует (например, он сможет векторизовать работу через какие-нибудь SSE инструкции процессора).

Совет по бенчмарку - если памяти не хватает, стоит по одному достаточно большому массиву пройтись 10000 раз. А лучше использовать готовые фреймворки для измерения скорости, вроде того де gbenchmark.

Еще, иногда полезно посмотреть на ассемблерный выхлоп. Вот, например, что происходит при -O3 опции компилятора. Он генерирует вообще идентичный код для обеих функций (развернув циклы)! И даже при -O2 оно одинаковый код выдает.

Без оптимизаций код разный, но там все не так как вы думаете. Вместо инструкции mov eax, dword ptr [rax + 4*rcx] в варианте с индексами используется инструкция mov eax, dword ptr [rax] для указателей. Это самое "складывание с указателем массива" вообще не отдельная операция - а вариант адрессации в инструкции mov. Они могут вообще одинаковое количество тактов занимать, это надо мануал по конкретной архитектуре процессоров читать.

Помогите составить запрос с помощью модуля requests

Вы имели ввиду "напишите за меня запрос с помощью модуля requests"?

На основе официального примера, с помощью модуля requests:

import requests
import json

api_key = "api_key"
secret_key = "secret_key"
api_url = "https://cleaner.dadata.ru/api/v1/clean/address"
headers = {
    "Content-Type": "application/json",
    "Authorization": f"Token {api_key}",
    "X-Secret": secret_key
}

# data
data = ["мск сухонска 11/-89"]

# requests
response = requests.post(api_url, headers=headers, data=json.dumps(data))

# check response
if response.status_code == 200:
    print(f"Success: {response.json()}")
else:
    print(f"Failed: {response.status_code}, {response.text}")

Что для вас Linux? Или как устроен запуск процессов

Файл дескриптор в Linux с примерами

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

std::function<bool(int, int)> comp = [](int left, int right)
  {
    return left < right;
  };
  Sort(vec, comp);

Сам компилятор тут это сделать не может, потому что ему тип к которму приводить-то неизвестен - он зависит от параметра шаблона T.

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

Sort<int>(vec, [](int left, int right)
  {
    return left < right;
  });

Но лучший вариант - не использовать std::function в шаблоне. Просто используйте какой-то typename U, у которого вы продполагаете существует operator(int, int). Если туда передать не function и не лябмду, оно не скомпилится:

template <typename T, typename U>
void Sort(std::vector<T>& vector, U comparison) {
    // Используете comparison, как-будто это std::function:
    if (comparison(1, 1)) return;
};


int main()
{
  std::vector<int> vec = { 1, 2, 3, 4, 5, 7, 6, 9 ,8 };

  Sort(vec, [](int left, int right) -> bool
  {
    return left < right;
  });
    return 0;
}

Скорее всего тут дело в кеше процессора. После первых запусков так получилось, что данные оказались в кеше.

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

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

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

Локальные переменные как правило выделяются в стеке, поэтому если между двумя for стоит определение ещё одной переменной, то она, вероятно, выделится на месте i. И поэтому новая переменная i попадёт в другую часть стека, где, если повезёт, будет 0.

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

Решение простое: надо везде в циклах for указать начальное значение i, тогда всё станет нормально, и перестановка определения count перестанет создавать такие совсем не странные эффекты.

Для начала просто убери цикл в классе. Циклы не вставляют прямо в класс, а вставляют в методы.

Ну просто проверяйте в operator*: если nullptr, то бросайте исключение.

Property<std::string> Name = Property<std::string>(_name);
…
std::cout << person.Name << std::endl;  // тут ошибки

почему у string требует перегрузку для cout?

Потому что Property<std::string> -- это не string. Хоть у тебя и есть Property<T>::operator T() const ничто в твоём коде не говорит о том, что Property<std::string> нужно пытаться приводить к string а не к какому-нибудь другому типу.

Для обращения к любому выражению по его имени в C++ имеется механизм поиска имен. Это довольно сложный и многоэтапный механизм, в результате которого исходя из контекста обращения и самого имени транслятор силится понять что же там такое прекрасное имел в виду писатель кода.

Насколько видно, базово механизм делится на две ветви: поиск квалифицированных имен и поиск неквалифицированных имен.
И именно в этот момент речь заходит о т.н. квалификации имени выражения.
Квалификация имени выражения тем полнее, чем точнее от самого корневого пространства имен (т.е. от ::), через все пространства имен и пространства составных типов, написано имя выражения.

Имя Process::WaitForExit, хоть и является уже квалифицированным за счет указания пространства типа, в котором метод объявлен, все еще остается недостаточно квалифицированным чтобы считаться полностью квалифицированным.
Вызов метода по его полной квалификации выглядел бы так:
process.::base::Process::WaitForExit(&exit_code);

Для чего это нужно. Как уже было сказано выше, UNL силится понять что там задумал писатель исходя из контекста кода и используемого имени. И иногда UNL в этом деле не преуспевает.
Например если шаблон типа наследуется от шаблона другого типа и пытается в своем интерфейсе использовать поля или методы своего родителя. Иначе транслятор просто не найдет в шаблоне родителя того, к чему там не было прямых обращений.
Или, например, более полная квалификация требуется для невиртуального вызова виртуального метода.
Полная квалификация всегда требуется для обращения к выражению внутри пространства имен из кода в другом пространстве имен.
Еще полная квалификация всегда требуется для обращения к статическим выражениям структур и классов снаружи этих структур и классов.

Для чего нужно было писать полную квалификацию конкретно в приведенном коде?
А кто его знает. Метод base::Process::WaitForExit[?] не является виртуальным чтобы сделать предположение о невиртуальном вызове.
Просто автору так захотелось, наверное.

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

Хотелось бы работать с бакендами, сайтами. Что-то в этом направлении.

• Любой учебник по Python;
  
• Учебник по СУБД (проектирование и sql);
  
• Документация/учебник по фреймворку;
  

Только так.

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