Dyikot

Это называется aliasing. Ну не ложится гладкая окружность (да и наклонные прямые) на прямоугольную сетку пикселей. SDL renderer похоже слишком примитивен и умеет красить только черные и белые пиксели. Если бы он где-то рисовал серые, картинка выглядила бы более гладкой.

Если вас это качество не устраивает, то вам надо найти какой-то алгоритм рисования окружности по пикселям и руками его реализовать (что-то вроде этого). Или реализовывать (сглаживание) anti-aliasing. Например, можно нарисовать сцену в текстуре в 2-3-4 раза больше нужного размера, потом ее отмасштабировать до размера на экране и уже это показывать.

Еще где-то пишут, что если использовать GPU а не software рендеринг в SDL то качество получше.

Проблема в том, что TInput с одной стороны выводится из первого аргумента, там у вас BuildableProperty<...,...,const Cursor&> согласно определению CursorProperty.

Но третий аргумент выводит TInput как просто Cursor, потому что это аргумент функции, а там передача по ссылке, даже в шаблонах, должна быть указана явно. Cursor != Cursor&, это разные типы.

Один из способов это починить - в объявлении SetProperty:

SetProperty(..., typename std::remove_reference<TInput>::type value)

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

Но вообще, по уму вам бы ваш шаблон BuildableProperty пофиксить. Вот у вас для каких-то случаев надо в нем ссылки использовать. Так может ссылки имеет смысл использовать всегда? Тогда вы в шаблоне BuildableProperty предполагайте что T, TInput - это просто типы, без ссыльности и константности, и внутри где надо расставьте &.

Не надо для каких-то случаев "передавать" в шаблон ссылки на какие-то типы.

Можно, но нужно ли? Польза только в том, что вы экономите 6 симолов (std:: уже можно убрать через using namespace std например). И то, только в случае, когда вам нужен именно вот такой вот указатель. А если вам нужен unique_ptr, а если вам нужен ваш собственный умный указатель, который как-то по другому память выделяет? А если вам надо не make_shared вызывать, а какой-то фабричный метод? Плюс это добавит кучу вопросов вроде, а как будет указатель на указатель? Указатель обычно идет после типа вроде int*, почему shared вы ставите перед ним?

В общем, возни много, а польза весьма ограниченная.

А зачем это делать?
Какая цель у такого изменения? Какую существующую сейчас проблему это изменение должно решить?

Писать сейчас не удобно? Это не проблема. C++ существует и развивается в согласии с основным принципом: любое явное всегда лучше любого неявного.
Многие люди в своем коде этот принцип стремятся нарушить и этим создают себе проблемы. Но эти проблемы решать должны сами же люди, а не изменения в языке.

Во-первых, оператор не виртуальный.

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

Если хотите использовать оператор из родительского класса, надо в дочернем сделать
using Base::operator=;

Что бы протащить этот метод в пространство имен дочернего класса, где компилятор его найдет.

Если нужно делать это при запущенном приложении, то делай это с помощью таймеров, а работу делать как в текущем потоке (например асинхронно) так и использовать ThreadPool

Если речь об организации запуска задачи вне запущенного приложения, то нужно использовать средства операционной системы, для windows это task scheduler, можно настраивать вручную а можно использовать командную строку или powershell или использовать старый COM Scheduler.Service (есть готовый NuGet пакет Microsoft.Win32.TaskScheduler)

Возможных вариантов бесконечно много. Начиная от Python-скриптов, запущенных через cmd, и заканчивая Windows Service, которые работают в фоне и сами запускаютя после рестарта винды

Task Scheduler и задача по расписанию...

В дизайне интерфейса можно передавать и копию и rvalue refernce. Что выбрать - решать вам, как создателю интерфейса. Если у вас предполагаются использование функций/лямбд без тяжелого состояния (связанные аргументы по значению), то копирование дешевое и не надо его вводить. rvalue reference всегда дешево, но у вас нельзя будет переиспользовать предикат между разными вызовами.

В функциях из algorithm используется передача по значению, что бы не ограничивать пользователя. Вы можете один раз написать нужный вам предикат и передавать его во все вызовы. Плюс исторически так сложилось. Когда оно все созадавалось, никаких rvalue reference и не было. Потом их добавлять и не стали, потому что в самом частом случае, если лямбду прямо в аргументах задавать, то она практически бесплатно передастся.

Там не используется передача по ссылке (lvalue reference), потому что это не так универсально в шаблоне. Если у вас какой-то const предикат, вы его в reference не передадите. А делать const & в интерфейсе нельзя, вдруг у вас предикат не константный?

И, если вы все-таки хотите передать ссылку, то можно передать std::ref(pred), тогда в шаблоне выведется передача по ссылке.

Объект, который вернет IEnumerable.OrderBy, сначала выберет всё, что вернет Where, а потом это отсортирует. Произойдет это в момент, когда будет вызван его метод GetEnumerator - напрямую или как часть реализации оператора foreach и т.п. - в этом и состоит его отложенное выполнение.

Вообще, методы LINQ, которые выполняются в отложенном реэиме, делятся, в свою очередь на две группы: работающие в потоком режиме (потоковые, streaming execution) - они обрабатывают каждый элемент входной последовательности по отдельности и сразу по получении - и не-потоковые, работающие с последовательностью как целым.
Where относится к первой группе, OrderBy - ко второй.

Background Service - правильный вариант.
Условия его работы и тех действий, которые надо выполнить можно настроить

Вообще, не вижу противоречия. У вас же там tfunc&&, его вы пытаетесь к void* привести и к нему применяете remove reference.

Попробуйте в ваш static assert добавить std::move и он обвалится.

Пока получилось через функцию.

#include <utility>
#include <iostream>

class Cursor {
public:
    Cursor(int aShape) noexcept : fShape(aShape) {}
    int shape() const noexcept { return fShape; }
private:
    int fShape;
};

template <typename T, typename TFactory>
class Lazy {
public:
    Lazy(TFactory&& x) : factory(std::move(x)) {}
    Lazy(const TFactory& x) : factory(x) {}
    T operator()() const { return factory(); }
private:
    mutable TFactory factory;
};

template <typename T, typename TFactory>
inline auto lazy(TFactory&& factory)
{
    return Lazy<T, std::decay_t<TFactory>>(std::forward<TFactory>(factory));
}

int main()
{
    auto arrow = lazy<Cursor>([] { return Cursor(42); } );
    std::cout << arrow().shape() << '\n';
    return 0;
}

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

Это не достаточно частая операция в С++, чтобы срочно надо было вводить новый оператор в синтаксис. Комитет занят более интересными вещами на годы вперед.

- Написать свой img2 и тянуть оттуда надо
- настроить сборку так чтобы он скопировал в запускаемый проект
-закинуть файлы в ресурсы resx

Судя по ошибке надо сделать простейшую публикацию на веб сервере а не запускать как файл. Да, придется разогнать IIS, apache или nginx (я на винде использую IIS, ибо проще всего, но кому-то может быть проще apache в составе чего-то типа wampserver).

template<class T>
concept is_exist_metod = requires(T t, std::string_view name) {
    t.GetMember(name);
};

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МГц)