Dyikot

Как я понимаю через выше aligment тем лучше?

Нет. Это бред. Тут не применимы термины лучше/хуже.

Alignment (выравнивание) - это просто свойство типа данных.
enum по умолчанию имеет тип int, соответственно и все его свойства наследуются. В С++ (с версии 17, если не ошибоаюсь) можно самому выбрать тип enum. Для выравнивания обычно действует простое правило - тип должен быть выровнен в памяти на границу кратную его размеру. Например у int размер 4 байта (обычно), и выравнивание должно быть по границе 4 байт. у char/uint8_t - размер 1 байт, соответственно ограничений по выравниванию нет, т.е. выравнивание по границе байта. Тип SDL_Color - это, видимо, структура, состоящая из 4 uint8_t (или что там в SDL используют для unsigned char), выравнивание для структуры берется из типа ее первого поля (если аттрибутами не задано другое).
Используй типизированный в uint8_t enum и будет тебе счастье.
https://en.cppreference.com/w/cpp/language/enum

Кстати, выравнивание, это не ограничение С++ - это ограничение процессора на аппаратном уровне. Правда почти все современные процессоры уже не имеют этого ограничения и нормально жуют не выровненные типы, но при этом операции выполняют медленнее, чем с выровненными. Фактически процы просто научились "маскировать" это ограничение. Поэтому ограничение в языке осталось.
К тому же все еще есть процессоры, где требование выравнивания действует, но это в основном что-то из разряда микроконтроллеров. На таких процессорах использование не выровненных типов приводит к ошибке шины и вылету программы.
Обычно тебе не нужно думать про выравнивание, т.к. компилятор об этом позаботится за тебя. Но бывают ситуации, когда программист должен это учитывать. Например когда ты читаешь поток бинарных данных из сети или из файла, и данные в потоке - это что-то сложнее, чем байты и символы.

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

Без разницы. Используйте то, что логичнее смотрится в коде. Разницу в производительности, во-первых, вы получите лишь в очень специфичных случаях (при передаче в функцию enum скорее всего окажется в регистре, а вот структура полезет на стек. В итоге enum окажется быстрее), во-вторых, только если читать вы будете миллионы стркутур. И то, вам должно не повезсти с кешем процессора и префетчером.

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

.layout {
    width: 1660px;
+   max-width: 100%;
    position: relative;
    display: flex;
    flex-direction: column;
    justify-content: flex-start;
    align-items: stretch;
    row-gap: 100px;
    margin: auto;
}

.layout {
-   width: 1660px;
+   width: 100%;
+   max-width: 1660px;
    position: relative;
    display: flex;
    flex-direction: column;
    justify-content: flex-start;
    align-items: stretch;
    row-gap: 100px;
    margin: auto;
}

Теория ваша верная, но отношение R3/R4 - не 3,6 (откуда вы взяли эту цифру?), а 7,5. Чтобы уточнить, надо учесть параллельное соединение сопротивления 560 Ом и сопр. нагрузки 5,1 кОм, с учётом емкостного сопротивления конденсатора.
Реактивное сопротивление 3,9 мкФ на частоте 20 Гц - 2 кОм. Комплексное сопротивление нагрузочной цепи будет примерно 5,4 кОм. В параллель с 560 Ом нагрузка получается 507 Ом. Соответственно уточнённое значение коэфф. усиления транзистора 507 / 75 = 6,8. Но опять-таки никак не 3,6!
Ну, а потери во входной цепи, снижающие общий коэфф. передачи, попробуйте прикинуть самостоятельно. Подкину вам только реактивное сопротивление для конденсатора 8,2 мкФ на частоте 20 Гц - 970 Ом.

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

Потому что лямбда не ялвяется 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, но если там есть асинхронные методы, лучше их дёргать. Ну а так, подгрузка данных порциями всё решает.

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