Но на этой волне я придумал некое решение с TypeIdGenerator:
надо на каждый класс завести TypeList его базовых классов и можно сделать шаблонную функцию, проверяющую для каждого T из этого списка id == TypeIdGenerator::GetId().
Печаль в том, что либо предков надо указывать вручную, либо реализовывать механизм наследования от всех типов из тайплиста, описанный в вашей статье.
Ваша реализация не обработает наследование, то есть кастование к предку. То есть вы определяете принадлежность классу, а не вложенность унаследованного класса в базовый. В коде вопроса, конечно, все обьекты отнаследованы от интерфейса, но они могут и друг от друга быть наследованы.
Естественно, я понимаю, что в любом случае придется применять dynamic_cast, под «без RTTI», я имел ввиду не вообще «без RTTI», а без своих надстроек над ним, ну или хотя бы с максимально простыми надстройками, или наиболее красивыми. В общем, это чисто исследовательский и эстетический интерес, с точки зрения работоспособности текущая схема вполне устраивает.
template<class T>
class NamedObject : public IObject, public T {}
И о том, чтобы сделать NamedObject не оберткой, а наследником и через это избавиться от своей (iaA) обертки на RTTI, и пользоваться только dynamic_cast. Минус в порождении кучи классов NamedObject, и заодно в этом случае затруднительно так легко проверить, что класс является каким-то из этих NamedObject, так что обертка опять возвращается. В общем и целом, я просто хочу найти более элегантное решение, буде такое существует.
Статья потрясная, спасибо большое! Однако, во-первых, мне она пока тяжело дается, а во-вторых, учитывая то, что было во-первых, у меня не получилось четко выделить ответ на мой вопрос из нее.
А разве % не устаревший способ? И да, можно, но я не умею писать регэкспы, плюс даже если я и напишу, то потом возможно захочу модифицировать и уж точно не смогу и снова придется писать.
При чем тут это? Основания теории вероятностей я и сам знаю, да вот только в классической теории вероятностей (это та, которая была до аксиоматической) теория меры нафиг не уперлась, так что вы говорите вообще не о том. И на кубиках вы не покажете типичную задачу теорвера, описанную в начале моего топлевел коммента. Не, ну, конечно и это можно, но для таких решений нужно стартовать свой govnokod.ru для математиков.
Что обсуждать-то? Писать «ваша статья — не очень, вы ничего не понимаете в статистике?». Минусовать за банальщину? Нет, ну если автор решил, что изобрел что-то революционное в методике преподавания теорвера — я всеми руками за, но очень советую дважды подумать, не будет ли это глупостью. Да и потом, что за навязчивая идея — рассказать теорвер пользуясь только парой кубиков? Теорвер — это математика, там вообще эти кубики нафиг не сдались, они и другие задачи используются только в качестве примеров.
У нас препод например любил примеры про детскую смертность приводить, это доставляло существенно больше, чем кубики. Хотя и без них не обошлось конечно.
Это хвостовая рекурсия. Ее можно легко преобразовать в цикл. Кстати, большинство компиляторов делают это сами, но к сожалению по поводу питона я не знаю, будет ли.
С вопросом про цветовую схему разобрался, как смог. То есть, пришлось цветовую схему динамически.
Если кому интересно, вот скриптскрипт, но тормозит он порядочно, ведь приходится переписывать xml файл.
И да, на питоне я не программировал до сих пор, потому ругаться не надо, а подсказывать надо.
надо на каждый класс завести TypeList его базовых классов и можно сделать шаблонную функцию, проверяющую для каждого T из этого списка id == TypeIdGenerator::GetId().
Печаль в том, что либо предков надо указывать вручную, либо реализовывать механизм наследования от всех типов из тайплиста, описанный в вашей статье.