"под капотом"?
он и так встроен в стандартную библиотеку просто там нет возможности стереть тип для объекта (а потом получить рантайм-объект с конкретным типом) если этот тип неизвестен разработчику (как например лямбды)
Как это должно работать в разных TU?
Ну это уже вопрос к подкапотной реализации. Сейчас виртуальные функции работают через несколько TU то есть компилятор собирает все возможные рантайм типы в программе и вызывает правильные виртуальные функции у объектов даже если они находятся в разных TU. И добавление фичи шаблонных виртуальных методов конечно потребует расширить текущий ABI но кажется что это вполне возможно реализовать. А что касается пропозала добавить магический метод visit к std::any - тут я ничего не могу сказать
Ну представь что есть такая система А: инлкуд Б, и определяет класс Derived наследник Base, с шаблонным виртуальным foo Б: определяет Base с шаблонным виртуальным foo=0, объявляет глобальную fun(Base*); В: инлкуд Б, объявляет и определяет класс MyType, определяет глобальную fun ptr->foo<MyType>(); } Теперь А ничего не знает про MyType, возможно он даже не может скомпилироваться с этим типом. В ничего не знает про Derived и тоже не может проверить можно ли вызвать функцию foo с таким шаблонным параметром. А теперь вспоминаем что компилируем мы их отдельно (или вообще Б,В это библиотека)
Да я уже придумал - фича виртуальных шаблонных методов никак не отменяет того факта что как и все остальные шаблонные функции эти виртуальные шаблонные методы должны будут находиться в хедере а значит у компилятора будет вся информация для того чтобы построить vtables для наследников из всех инстанциированных шаблонных методов. Я не вижу тут каких-то особых технических сложностей
генерация vtable предполагает ПОЛНЫЙ список виртуальных функций
Ещё раз: это невозможно в рамках нескольких TU
ладно, я понял, это потребует от линковщика замерджить виртуальные таблицы из разных TU но это вполне себе реализуемо
Обсуждают сегодня