Dyikot

Попробуй рядом другую команду
Add > Reference и выбери проект либы

Метод ContentUIElement::SetContent у тебя сейчас реализует прямой контроль. Код работает с переданным контекстом и указывает ему что-то делать.
Загвоздка у тебя в том, что действия кода полагаются на типизацию элементов контекста. В этом случае люди часто принимают чисто ошибочное решение делать проверку типа и действовать исходя из этой проверки.
Такой подход мог бы подойти для питона или JS, но не на плюсах, где он является источником ошибок.

В контексте метода ContentUIElement::SetContent полностью все объекты, включая и объект по указателю this имеют два типа: статический тип и динамический тип. Оба типа могут быть одинаковыми, но нередко они разные.
Игры со сменой статического типа в рантайме чреваты проблемами и гроздьями условий обхода этих пробелм.

Что же тогда надо делать? На помощь приходит виртуальный интерфейс и инверсия контроля.
Тебе поможет шаблон визитера. Описание у Фаулера, конечно, хтоническое, но суть передает хорошо. А понять этот шаблон довольно просто на твоем же примере.
Что тебе требуется сделать? Если content имеет один динамический тип, то выполнить А. А если content имеет другой динамический тип, то выполнить Б. В иных же случаях выполнить общее поведение.

Пусть у IData появится еще один метод:

void SetupContentElement( ContentUIElement& element )

Пусть по умолчанию этот метод делает то, что находится в ветке else метода ContentUIElement::SetContent, а реализации для UIElement и TextContent выполняют свой код настройки самостоятельно.
В этом случае код ContentUIElement::SetContent сводится к вызову content->SetupContentElement( *this );.

При этом код получает эффект легкой расширяемости. Где сегодня два частных случая, там завтра будет уже три или пять. Еще одним важным эффектом для кода будет малое знание. Коду ContentUIElement больше не надо знать о типах UIElement и TextContent.
Если есть какие-то проблемы с доступностью интерфейсов или семантикой вносимых изменений, эти все проблемы совсем не сложно убрать выстроив отдельную систему типов строго под задачу посещения.
Если не нравится вносить в IData определенный виртуальный метод, делая его абстрактным классом, а не интерфейсом, то решение простое: плюс один шаг базового типа от IData, в котором и определено общее поведение, и наследоваться уже от этого типа дальше, а не от IData напрямую.

Зависит от того, как вы планируете эти chunk использовать. subrange - гораздо эффективнее, потому что ничего не копируется. Но при этом он не может использоваться после уничтожения оригинального items, или chunks (если внутри у chunk все-таки копия).

В приведенном вами коде вы с чанками работаете локально, ни в какие хранилища или очереди для обработки в других функциях или потоках не складываете, поэтому вам подойдет subrange.

Ну когда на Винде, то все необходимое для запуска программы у тебя уже установлено(.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=;

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

Если нужно делать это при запущенном приложении, то делай это с помощью таймеров, а работу делать как в текущем потоке (например асинхронно) так и использовать 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;
}

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

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