Dyikot

Ну когда на Винде, то все необходимое для запуска программы у тебя уже установлено(.net или что у тебя там). Оно работает как отдельная программа не связанная с твоим приложением. Когда ты запускаешь свое приложение, все эти среды выполнения библиотеки и прочее, продолжает работать отдельно и ты в своем процессе видишь только свой процесс.
В линуксе нет сред выполнения виндовс и когда ты делаешь под него сборку, то внутрь этой сборки пакуется все необходимое для запуска приложения и когда ты в линуксе это запустишь, то запускаются среды выполнения в том же процессе. Поэтому и разница.

Чтобы на Винде увидеть реальную цифру, тебе нужно взять память своего приложения(8мб) и прибавить к ней ещё библиотеки и рантайм, которые работают в отдельных программах и процессах.

это просто разница в методике подсчета.

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

получается что линукс завышает использование памяти (но если есть память объявленная линуксом то программа гарантированно запустится) , а винда занижает ( так что если памяти в притык, её может и не хватить)

Это называется 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=;

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

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

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

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

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).