Можно поподробней? Куда копать?

Иерархия подсказывает что это просто свойства Property, updateable, signaling etc. Которые можно выразить может даже битовой маской. И это может быть просто Property<T, Policy> Ну и дальше рулить реальными методами в зависимости от Policy. template<class T> using UpdateableProperty = Property<T, PropertyPolicy::Updateable>

Каждый уровень также добавляет необходимые ему данные Имлементируют onChange() и хранят: 1) Updatable<> - ссылку на объект, который нужно пометить грязным, а также два флага "грязный", "был грязным". 2) Plain<> - просто булеан флаг, что грязный Реимплементируют onChange() и хранят: 3) Signal<> - подмешивает интерфейс сигнала (shared<структура синхронизации>), чтобы пометить сразу несколько объектов грязными 4) MuxSignal<> - см выше, но также еще и "текущую цель", работает также как сигнал, но только на один слот, который можно поменять в любой момент

Потенциально добавятся еще возможные "перегрузки".

Я думаю попробовать чтото вроде template<typename T, typename...Policies> Property: public Policies... { onChange() { Policies::onChange().... (ну или как нибудь по очереди вызвать) } } Т.е. та же идея сборки по очереди, но слегка по другому using Prop = Reimplement<Implement<Property<T>>; vs. using Prop = Property<T, Implement, Reimplement>;

Я б делал одним классом. Всякие наследования всё равно overhead. Если нужны доп. данные, можно сделать просто policy-based layout.

Не слышал про policy-based layout, это как?

using data_type = ProrertyLayout<T, Pollicy>

и храним мембером?

допустим у меня bidirect list, front я храню вообще всегда, а back/size опционально получаю 4 варианта layout: {front,back,size},{front,size},{front,back},{front,size}

тут я бы выкинул варианты {front, size}, кстати, он дважды повторяется

поправил. вариант с чистым front

тоже исправил

ну и зря, вариант с отсутствием back для bidirect тоже возможен, nullptr вполне себе sentinel

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

Из контейнера да, из итератора нет.

итератор на конец мы не всегда сможем получить, так что я бы предпочёл вариант с началом и концом

в случае отсутствия back end всегда nullptr, это просто не циклический список

а, ну если имеется в виду rend, то да

или хотя бы end от которого можно делать --

если не нужен reverse проход и вставка в конец, то как бы вот, можно

ну это очевидно, но не моё предпочтение

Это просто возможности. Реально пользую только bidirect с front/back и чаще всего без size.

норм выбор

А, ну и forward тож без size.

тоже норм, но в целом он менее юзабален

часто он оооочень юзабелен это доп данные с минимальным overhead если их нет

последний раз когда хотел им воспользоваться я отказался от идеи им пользоваться

Да ладно. Это ж простейший из списков. У тебя есть head и у каждого элемента next. Да, у него много что O(N), ну и что... Им не менее удобно пользоваться.

ну у меня так получилось, что не стал не нужен