G
ну у тебя реально очень странная архитектура
Size: a a a
2020 August 16
RM
Я слышал что если классы виртуально унаследуются, то самый нижний класс в иерархий является рычагом для создания всех выше классов, но в моем случае ModuleTest создается сам по себе из main точки входа в .dll, не вызовет ли это проблем у классов плагинов, так как они виртуально унаследованы, а конструктор ModuleTest вызвался сам по себе
G
и нейминг тоже, если честно. Не понимаю, зачем делать Helena::HFWhatever, если можно Helena::Whatever
RM
Я знаю для чего нужно виртуальное унаследование, чтоб базовый класс от которого мы наследуемся был только один раз создан, то есть, был общим для всех классов плагинов, но как мне проверить, что разработчик унаследовался виртуально?
A
А ты как себе представляешь в компайлтайм индексировать типы?)
Boost/std::type_index
A
протаскивай контекст внутрь плагинов если им нужны другие модули
+
RM
Boost/std::type_index
Да не листай ты там, это вопрос риторический
RM
Там у меня нет проблем
RM
У меня своя система индексаций уже имеется, щас вопрос в другом
RM
протаскивай контекст внутрь плагинов если им нужны другие модули
Не увидел твой ответ, извини, щас только заметил, когда Алекс ответку кинул
RM
Такой подход нарушает иерархию, но уже обсуждался мной как один из вариантов
RM
Это крайний случай
G
придумать иерархию, чтобы потом с ней бороться
RM
Можно ли как то проверить что плагины виртуально унаследовались?
RM
Чтоб разработчик случайно не написал public ModuleTest
🦊
придумать иерархию, чтобы потом с ней бороться
Я пытался до него донести, его уже не спасти
G
пора в стандарт писать пропозал std::is_virtually_inherited
RM
а че нету что ли возможности чекнуть?
A
Через хеш мапы - это затратно
Там же O(1)
RM
Там же O(1)
O(1) хеш мапы и O(1) вектора не одинаковы же