Dyikot

Абсолютно неважно. Вы их вообще можете обозначить буквами или эмодзи. Суть автомата от этого не поменяется.

Потому что лямбда не ялвяется 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;
}

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

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

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

Только если отключить git в visual studio (Tools-Source Control-Plug-in Selection). Отдельно никак

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

Ну, у вас person.Age - это Property<int>. Как его в cout выводить вы нигде не определяли, про это компилятор и ругается. У Property вы, правда, определили приведение к int. так-что вот это сработает:
cout << static_cast<int>(person.Age);

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

Вам надо также, как вы operator<< для Person определили, определить его для Property<T>.

IMHO, тут нужет обычный рекурсивный алгоритм, только функция проверки получается довольно сложная.
Я бы написал функцию, которая по номеру позиции выдаёт ограничения на углы (min и max для каждого угла) при условии, что предыдущие позиции заполнены, а следующие ещё нет. Затем останется выбирать из оставшихся квадратов те, которые подойдут под ограничения на следующее поле, пробовать подставить их и решить ту же задачу с частично заполненным полем и оставшимися квадратами.

Так как тут UI вам нужен всего один поток и выключение обновлений контрола до завершения операции.
Так что используйте VirtualMode как тут

https://learn.microsoft.com/en-us/answers/question...

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

Что это означает на практике. После 4й стадии трансляции формируется модуль трансляции, содержимое которого и компилируется в объектный файл. Код модуля трансляции должен быть исчерпывающим, в нем должны находиться все необходимые для компиляции определения. А определение шаблона относится именно к таким требуемым.
Значит определение используемого в модуле шаблона должно быть внесено в модуль трансляции. А это значит что или определение должно быть вписано в тот .cpp файл, в котором шаблон инстанцируется, или определение должно быть добавлено через директиву #include.

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

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

Широкой практикой является разделение кода шаблонов на несколько типов файлов. В .h файлах обычно делают или объявления шаблонов функций, или определения шаблонов классов. В .hpp/.inl файлах обычно делают определения шаблонов функций и шаблонов методов.
При этом .hpp/.inl файл очень часто включается в самом низу .h файла с его объявлениями.
Моя личная рекомендация: использовать в таких случаях расширение .inl (от слова inline), т.к. для .hpp столь же широко закреплено взаимоисключающее с .h значение заголовка C++ кода. И видеть эти два расширения в одном проекте обычно бывает странно.

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

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

Foo.h

template <typename T>
struct MyStruct
{
    void foo(T arg);
};

#include "Foo-inl.h"

Foo-inl.h

template <typename T>
void MyStruct<T>::foo(T arg)
{
    // some code
}

Также, если вы используете специализируете шаблонный параметр в определении методов класса методов, то такие методы можно поместить в .cpp файл.

Если делать в одном потоке или запустить в другом с помощью new Thread(...).Start() то все работает.

А потом вы оборачиваете всё в Invoke. Естественно это работает. Только о многопоточности тут речи быть не может, ну и накладные расходы сначала на запуск в треде. потом на invoke. Работает оно так же как без треда, потому и показывает.

Если вы то что в таске обернёте в invoke оно тоже заработает, только так тоже неправильно.

Что вообще тут лучше использовать асинхронность или многопоточнсть?

Что-то мне подсказывает что ни то и ни то. Хз что такое Serialization.DownloadTable, но если там есть асинхронные методы, лучше их дёргать. Ну а так, подгрузка данных порциями всё решает.

Ну и теорию подтянуть надо, и практику.

Для Windows Form нужно использовать SynchronizationContext.
Вызов таска в отдельном потоке Task.Run(...).

В отдельном потоке должно делаться все, что не касается обновления UI контролов. Как только все данные для отображения подготовлены, вызываете synchContext.Post(...) для обновления UI

Нет виртуального деструктора у IContainer, а удалять пытаешься полиморфно.

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

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

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

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