Dyikot

template<size_t Number> 
requires (Number <= 1000)
class MyClass { };

0) Где код?
1) Настолько ли важно замеры проводить с помощью АЦП? Может простейший ФВЧ + компаратор + таймер в режиме input capture? Это проще с программной точки зрения, а рассыпуха копейки стоит
2) Какие параметры АЦП? Какая частота АЦП, время семплирования, используется ли прерывание по окончании, или блокирующая функция в прерывании?
3) Правильно ли я понял - вызывается обработчик 3 таймера? Если так, то другой вопрос - зачем? TIM3_TRGO может напрямую запускать преобразование
4) DMA? Да! И ещё раз - да!
5) Не понял, зачем тут упомянут TIM2 - если он используется для других задач, стоит выключить на время отладки АЦП, что бы не мешал.
6) "Симуляцию произвожу в proteus" - не надо, отлаживать надо на реальном железе, симуляторы в таком виде не используются, только изредка qemu для юнит тестов
7) "Это он не может так быстро обработать" - если симулятор не может обрабатывать в реальном времени, она начинает обрабатывать не в реальном времени, но на логику кода это никак не влияет, просто занимает больше времени.
8) 8МГц это мало, если нет гонки за каждым миллиампером (в таком случае F1 выкидывается, ставится L0/L1), лучше выставить максимальную частоту (72МГц)

Если правильно понял вопрос, то можно сделать так:

Добавь в IProperty чисто-виртуальную функцию Copy. А дальше уже каждый конкретный класс себя будет уметь копировать.

#include <iostream>
#include <string>

struct T {
    int x;
    std::string y;
};

T Deserialize(std::istream& stream, auto T::*... properties)
{
    T object = {};
    auto FillObject = [&object, &stream] (auto property)
    {
        stream >> object.*property;
    };

    (FillObject(properties), ...);
    return object;
};

int main()
{
    T r = Deserialize(std::cin, &T::x, &T::y);
    std::cout << "<" << r.x << "> <" << r.y << ">" "\n";
    return 0;
}

Что сделано: исправлен вызов FillObject (важно), уточнён тип properties (лучше).

По правой кнопке не помню, хотя вроде бывают.
При щелчке показываются иконки вокруг, например, в Incredible Machine. Или во многих квестах. Или в Fallout 1/2.

Что контекстному меню мешает.

1. Плохая раскрываемость (discoverability, возможность найти всё это тыком и интуицией). Игры всё-таки должны собирать большую публику необученных пользователей, верно? Я когда-то учил одну даму ходить по Witness (у неё FPS-управление, но никакой реакции не нужно) — так и не смог. Сам прошёл с большим удовольствием, хотя посторонних головоломок нашёл от силы половину.

Опытный пользователь рабочих программ просто привык — и то, например, в редакторе Unreal Tournament есть одно очень подлое контекстное меню, которое хрен раскроешь (на заголовке каждого из четырёх видов: спереди, сверху, слева, в перспективе).

В том же Fallout 1/2 есть команда «оттолкнуть» — неписи ходят по своим делам, и если он загородил нужный проход и никуды, приходится на него действовать этой командой. Понятна только через инструкцию.

2. Нежелание превращать игру в рабочую программу. Чем дальше интерфейс игры от программы, тем лучше иллюзия. Некоторые авторы — сейчас, правда, это сложно, с управлением из шести осей и десяти кнопок — вообще не делают интерфейса. Хоть «↑ = зайти» да и делают даже в играх вроде Braid и Fez.

3. Если объект подвижный, бывают глюки, когда ты щёлкнул на него, а он ушёл или даже погиб. Если статус-панель опустела, пока мы нажимаем, мы жмём в никуда. Если меню исчезло — жмём куда-то на игровом поле. Подобное больше годится для чего-то неподвижного и прочного.

4. Теряется правая кнопка мыши. У опытного игрока, который использует всю клавиатуру и даже больше, вдруг отбирают одну кнопку.

5. Опять-таки раскрываемость — если есть команда, скажем, «патрулировать», не очень понятно, что кнопка P действует, даже если контекстное меню не раскрывать.

6. Со всей этой раскрываемостью, боковыми панелями и прочим интерфейсом контекстное меню кажется излишним, и годится в двух случаях: или нет статус-панели, или она не отображает наш объект.

7. А если ещё важно заранее раскрыть и момент улучить — меню мешать будет.

В общем, контекстное меню может пригодиться, но, во-первых, в интерфейсе, а не на игровом поле. Ну или в медленной игре, где игровое поле мало чем отличается от интерфейса. А во-вторых, оно по определению дублирует команды, а если в игре их немного (иначе хрен этой игре обучишься), ничего не стоит вывалить их все другим методом. А те игры, которые делают доступ ТОЛЬКО через контекстное меню — ну, учитесь у Fallout 1/2 и Incredible Machine.

UPD. Вспомнил. В Mafia и некоторых частях Hitman, если действий вокруг много, по кнопке «Действие» выводит меню: что выбираешь?

В наше время можно просто проверить: godbolt.org

И clang и g++ и при локальном и при глобальном объявлении кладут 1 на стек.
Правда, clang чуть поумнее и выдает warning:

warning: temporary whose address is used as value of local variable 'Number' will be destroyed at the end of the full-expression [-Wdangling]

Нельзя надеяться, что по этому адресу останется лежать 1. В более сложных случаях этот адрес может быть переиспользован под что-то еще. Обращение по такому указателю - UB.

Не пиши так, пожалуйста.
Перед нами продление жизни временного объекта.
Когда ссылка исчезнет — а она исчезнет после точки с запятой — указатель будет смотреть в никуда, и только от Ктулху зависит, когда переменную перезапишут.
Правильно так:

const int& ref = 1;
const int* Number = &ref;

Данные могут лежать где угодно — теоретически на стеке, но оптимизатор может перекинуть их и в сегмент данных.

В общем, правило. Продлённый объект живёт, пока живёт та ссылка, что его продлила. Ссылки и указатели, что сделаны уже из этой ссылки, не в счёт: Си++ всё-таки не «мусорный» язык. Временный объект живёт до точки с запятой, за исключением нескольких случаев: явная команда придержать объект (о которой у нас и речь), создание/копирование массива (для простоты компиляции и чтобы не раздувать стек), с Си++23 в команде «цикл по объекту» ради безопасности и предсказуемости.

Как рендер реализован например в игровых движках

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

1) Принимать рендер в конструкторе.
Только одна проблема надо для каждого объекта передавать этот рендер. Что не хочется и выглядит как то не очень.

Нормально выглядит. DI через конструктор.

ВСЕ ПРИМЕРЫ ЖИВЫЕ, у меня перед глазами.
• stream.flush — физический сброс данных на устройство (при выводе) или сброс буферов (при вводе) имеет место только с реальным устройством, а написанные прикладным прогером потоки редко с ними работают, потому пустая.
• Импортёр из системы управления предприятием, который для каждого, например, рецепта производства вызывает callback. Если рецепты не поддерживаются — ничего не делать.
• В каком-то виджете Qt напрочь убираем реакцию на колесо мыши.
• Программа использует для ускорения кучу кэшей, которые перед импортом данных выкидываются. Если выкидывать нечего — функция compactMemory пуста.
• Или твоя фигура-квадрат, для которой поворот ничего не делает.

В комментарии Wataru уже указал на вероятную проблему. Метод класса первым аргументом принимает указатель this на объект класса, который этот метод вызывает. То есть вызов objectName.foo(100) компилируется в нечто такое foo(&objectName, 100).
Только вместо std::bind проще использовать лямбду. Если в списке захвата лямбды указать this или =, то всеми видимыми методами класса в лямбде можно пользоваться как обычно, https://godbolt.org/z/e9z76vTY7.

#include <array>
#include <algorithm>
#include <functional>
#include <iostream>

class Container {
public:
    bool isZeroLambda() {
        return std::ranges::all_of(std::begin(ar), std::end(ar),
                [this](auto x) { return isZeroValue(x); });
    }

    bool isZeroBind() {
        auto pred = std::bind(&Container::isZeroValue, this, std::placeholders::_1);
        return std::ranges::all_of(std::begin(ar), std::end(ar), pred);
    }

private:
    bool isZeroValue(int x) { return x == 0; }
    std::array<int, 3> ar{};
};

int main() {
    Container c;
    std::cout << c.isZeroLambda()
        << '\n' << c.isZeroBind();
    return 0;
}

Подсказка: вот то число, что у вас в конце выводится - это 2^64-1. Еще подсказка: size_t на современных платформах имеет размер 64 бита.

У вас переполнение. Вы там из 0 вычитаете 1 в итерации цикла, получаете самое большое число, представимое в 64-битном типе.

Надо переписать цикл на while и делать из него break по достижению 0. Или тип переменной сменить на знаковый.

Как я понимаю через выше 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 Ом.