Грабли 2: Виртуальное наследование

Давно пора запретить множественное наследование. Описанные в топике неоднозначности только создают головную боль для всех.
Лучше использовать Фасад.

Ох и отхвачу ж я сейчас

macton.smugmug.com/gallery/8936708_T6zQX#!i=593426709&k=ZX4pZ

    JustVisiblePlusUpdate(bool visible, bool active)
        : JustVisible(visible)
        , VisualActivity(visible, active)
        , Renderable(visible)
        , Updatable(active)
    {
    }

Воу, сколько раз будет выполнен конструктор Renderable, 1 или 3 раза?

Если это геймдев и смежные области (реалтайм компьютерная графика), то вместо такой архитектуры со временем приходят к Data Driven и Data Oriented подходам. А когда к ним приходят то Object as a pure aggregation самое оно. По сути — у нас уже нету никаких объектов, есть только массивы (часто некоторые типы наподобе позиции разбивают по елементам на отдельные массивы заради SSE оптимизаций — SoA vs AoS), и в этих массивах содержатся примитивные елементы: updatable, renderable и прочие. Связи между елементами — data driven и задаются извне.

Компонентно ориентированное программирование как раз избавляет от граблей множественного наследование и предоставляет механизм равнозначный подмешиванию интерфейсов.

В нашем случае было принято решение отказаться от разделения на Renderable и Updatable, ограничившись одним базовым VisualActivity. Это добавило некоторую избыточность

Это же ужасно. Стоило бы просто отказаться от наследования реализации, заменить её аггрегацией и множественным наследованием «интерфейсов».

По-моему, тут просто оверинжиниринг и грабли именно в этом, а не в виртуальном наследовании. С++, конечно, дает себе в ногу выстрелить в этом плане, но зачем это делать? Непонятно, зачем вообще усложнять модель и разделять Renderable и Updatable. Во-первых, кода на этом мы ненаэкономим. Во-вторых, скорее всего, и в читаемости ничего не выиграем, бедным программистам контролов просто надо будет писать больше кода.

Тут вполне можно обойтись одним классом типа Widget и от него наследоваться. «Фасад» он будет или просто тупой как валенок, это уже другой вопрос. По идее, если грамотно итерфейсы использовать, тогда двойное наследование не должно быть нужно вообще. В случае когда один контрол явлется одновременно двумя другими ИМХО лучше использовать составные контролы-контейнеры.

Еще (судя по тому что я видел/писал) чаще всего виртуально наследуются от единственного класса на весь API, тогда меньше путаницы. Но даже этого, как оказывалось, проще избегать, чем мучаться потом.

Но рассмотрим подробнее, откуда взялось предположение, что приведенный код должен приводить к вызову конструктора Renderable::Renderable(bool visible) вместо Renderable::Renderable().

От незнания языка С++? :)

Вы (вроде бы) забыли рассказать про одну важную проблему, связанную с виртуальным наследованием. Вариант наследования (обычное/виртуальное) выбирается при описании наследника, поэтому нельзя описать класс таким образом, чтобы гарантировать, что все его наследники унаследуются от него виртуально. Решается с помощью простой идиомы:

class ancestor_imp {
  // implementation of ancestor
};

class ancestor : virtual public ancestor_imp {
  // empty dummy class
};