Добрый день

Давеча мелькнула фраза
Конечно это так, и это все знают. Но ПОЧЕМУ? В чем причина такого ограничения?

Спасибо

Да, но бесконечности ведь нет. Шаблоны ведь это просто подсказка компилятору "скопируй этот метод заменив T на double", то есть сахар для перегрузки. А ведь все типы, которые будут использованы для данного метода, известны заранее на этапе компиляции. Следовательно и vtbl можно сформировать. Но это теория. А на практике в С++ куча ограничений из-за сложности реализации какой-то фичи в компиляторе. То есть фичи нет просто потому, что её сложно сделать, и всё. Так и здесь.

все верно кроме "фичу слишком сложно реализовать".

фичи нет не потому, что сложно сделать,
а потому, что видимо комитет не видит в ней надобности.

с другой стороны, комитет мыслит глобальнее.
они на с++20 анонсировали статическую рефлексию.
в теории можно будет делать вещи позаковыристее,
чем какой то там шаблоно-виртуал.

Про "бесконечности ведь нет", "технических ограничений не существует" и "все верно кроме "фичу слишком сложно реализовать"" как-то я сомневаюсь. С библиотеками тоже сложностей нет?

Например:
1. В библиотеке SomeLibrary есть интерфейс с шаблонным методом

C++ (Qt)
class ISomeClass
{
    ...
    template <class T>
    virtual void doSomething(T value) = 0;
}

и в ней же есть функция, которая создаёт объект с таким интерфейсом, в котором метод реализован, допустим, для типов double и int (но в общем случае не известно, для каких типов).

C++ (Qt)
ISomeClass * makeSomeObject();

2. Приложение использует библиотеку SomeLibrary:

C++ (Qt)
QWidget * widget = new QWidget();
ISomeClass * some_object = makeSomeObject();
some_object->doSomething(widget);

Что должен сделать компилятор?

Комитет много чего анонсирует, только доживём ли .

В динамической библиотеке?

шаблоны имеют иммунитет против "множественного определения" по разным. ед. трансляций.

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

вот вам немножко другой пример "издалека".

рассмотрим простейший класс:


здесь все просто.
как быть с шаблоном?


стандарт говорит: на усмотрение конкретной реализации.

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

или определить его в любой первой попавшейся,
которую транслирует.

или вообще во всех подряд,
а линкер потом повыкидывает лишнее.

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

в отношении шаблоно-виртуалов мог бы сработать аналогичный механизм.

для каждой ед. трансляции компилятор может нагенерировать отдельную версию vtbl
а линкер, при резолве символов их потом все смержит в одну.

пока нет нарушений ODR, он просто сошьет из нескольких vtbl одну,
выпиливая дубликаты, и добавляя новеньких.

Виртуальные методы нужны для их последующего переопределения.
Допустим, вы пишите библиотеку, где в одном из классов описываете шаблонный виртуальный метод, собираете эту библиотеку в dll и отправляете в мир. Все таблицы vtbl уже сформированы и помещены в эту dll.
Теперь пользователь вашей библиотеки решает создать класс-наследник от вашего класса и переопределить эту виртуальную шаблонную функцию, инстанцируя ее своим классом.
Как компилятор/линкер сможет изменить vtbl вашего класса из dll, что-бы сделать возможным вызов клиентского метода, через указатель на базовый класс?

Тогда это нарушает весь текущий принцип dll. Тем самым давая такие просторы для багов/некорретных использований и переборов, что компиляция будет минут по 20 длиться простенькой dll.

PS сам смысл dll что они кроют в себе неизменяемый функционал. А вы предлагаете их превратить в плагины с неопределяемой сложностью.