Шаблонный виртуал

[Old]

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

Динамические библиотеки загружает специальный загрузчик, как правило, это часть ОС.
Предлагаете его научить расширять vtbl базовых классов из dll, с учетом "хотелок" клиентского кода?
Или загрузку dll + резольвинг символов из нее + расширение vtbl помещать в код самой программы?
Жирновато выглядит, особенно с учетом того, что одна dll может тянуть за собой другую и т.д.
Сейчас в объектном файле vtbl's просто секция с константными данными, с известным компилятору расположением таблиц, а так придется их генерировать на лету и модифицировать код прописывая их адреса. Можно конечно ввести еще один уровень косвенности для таблиц, но это уже скажется на времени вызова методов...
 

[__Heaven__]

Old, а без наличия шаблонов при наследовании от класса из библиотеки мы же можем добавлять новые виртуальные методы... Получается таблица расширяется?

[Old]

Old, а без наличия шаблонов при наследовании от класса из библиотеки мы же можем добавлять новые виртуальные методы... Получается таблица расширяется?

Таблица своя на каждый класс. Расширяется таблица нового класса наследника, таблица базового класса не меняется.

[_Bers]

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

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

1.
это какой такой текущий принцип dll нарушается?

2.
я ничего не предлагаю.

3.
что вы подразумеваете под "неопределяемой сложностью" ?


ps я специально подчеркнул выше мысль: исходная dll не меняется.
проблемы?

[Igors]

vtbl на стороне приложения была модифицирована с учетом "новеньких".

Да, именно это я имел ввиду

ps я специально подчеркнул выше мысль: исходная dll не меняется.
проблемы?

Не меняется код либы, а данные у нее свои для каждого приложения где она загружена. Поскольку VMT хранятся в данных - не видно каких-то принципиальных, непреодолимых трудностей.

[ViTech]

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

в какой то момент он знает про int и double,
на этот момент он инстанцировал:

Код:

virtual void doSomething(int  value);
virtual void doSomething(double value);

увидев запись:

Код:

some_object->doSomething(widget);

он просто инстанцирует ещё одну перегрузку:

Код:

virtual void doSomething(QWidget * value);

в отсутствии шаблоно-виртуалов,
все тоже самое можно сделать руками.

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

А есть уверенность, что компилятору будет откуда код копипастить? В частности для чистых виртуальных методов, как в моём примере. Приложению доступны заголовки с объявлениями интерфейса ISomeClass и функции "ISomeClass * makeSomeObject()", всё остальное в бинаре. Каким конкретным объектом инициализируется интерфейс ISomeClass в функции makeSomeObject пользователь может никогда и не узнает. Класс, который реализует интерфейс ISomeClass, используется внутри библиотеки и снаружи никак не доступен. И опять тот же вопрос: "Что должен сделать компилятор?", когда в приложении увидит новую перегрузку для ISomeClass::doSomething().

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

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

Если фичу не сложно реализовать, то почему её не сделали? Igors вот она бы вот помогла. Да и другим страждущим. На Ваш взгляд, по каким причинам комитет не видит в ней надобности? Статическую рефлексию, концепты и всякие метаклассы может ещё очень долго ждать придётся. А то уже хоть что-нибудь бы было, это же не сложно .

[Igors]

И опять тот же вопрос: "Что должен сделать компилятор?", когда в приложении увидит новую перегрузку для ISomeClass::doSomething().

Скомпилировать новую перегрузку и адрес этой перегруженной ф-ции поместить в новый слот VMT. Под "копипастой" (как я понял) подразумевается как это делается сейчас

Код

C++ (Qt)
class MyClass {
..
  virtual void foo( int a ) { fooPrim(a); } 
  virtual void foo( double a ) { fooPrim(a); } 
  virtual void foo( Vector3f a ) { fooPrim(a); } 
  ...
  template<class T>
  void fooPrim( const T & a ); 
..
};

Ну как-то не солидон 

[Old]

Скомпилировать новую перегрузку и адрес этой перегруженной ф-ции поместить в новый слот VMT.

Если бы все было так просто. А в vtbl всех базовых классов этот адрес кто будет помещать?
Должна остаться возможность вызывать этот метод через указатель на объект базового класса.

[ViTech]

Скомпилировать новую перегрузку и адрес этой перегруженной ф-ции поместить в новый слот VMT. Под "копипастой" (как я понял) подразумевается как это делается сейчас.

Акцент на том, что речь идёт о чистом виртуальном методе. В общем случае, когда объявление (declaration) сигнатуры есть, а определения (definition)/тела метода нет. Когда компилятор собирает библиотеку, у него есть исходники класса, который реализует интерфейс, и он может собрать библиотеку. Когда же компилятор собирает приложение с той библиотекой, у него уже нет доступа (исходников) к тому внутреннему классу. Поэтому и спрашивал, откуда компилятор будет брать код, чтобы "доинстанцировать" методы, появившиеся в приложении для того конкретного внутреннего класса библиотеки .

[_Bers]

А есть уверенность, что компилятору будет откуда код копипастить? В частности для чистых виртуальных методов, как в моём примере. Приложению доступны заголовки с объявлениями интерфейса ISomeClass и функции "ISomeClass * makeSomeObject()", всё остальное в бинаре.

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

итоговая таблица может отличаться от зашитой в dll
наличием "новеньких".

Если фичу не сложно реализовать, то почему её не сделали? Igors вот она бы вот помогла. Да и другим страждущим. На Ваш взгляд, по каким причинам комитет не видит в ней надобности? Статическую рефлексию, концепты и всякие метаклассы может ещё очень долго ждать придётся. А то уже хоть что-нибудь бы было, это же не сложно .

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

На Ваш взгляд, по каким причинам комитет не видит в ней надобности?

комитет руководствуется идеомой "программирование через страдание".
которая гласит:
"если отсутствие некоторой технологии не причиняет вам боль и страдание,
значит эта технология вам не нужна"

или попроще: нехай тащить в стандарт всякий хлам только потому,
что полторы калеки решили, что это очень важная и крутая фича.

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

признать уже факт существование процессов,
например?

(стандартизировать работу с процессами,
и межпроцессовыми коммуникациями.
в настоящий момент свой прототип
катают менторы boost::interprocess/boost::asio)


зы: я тоже всему руками за шаблоно-виртуал.
при их наличии становится возможным запилить
почти почти полноценную интроспекцию,
например.

[_Bers]

А в vtbl всех базовых классов этот адрес кто будет помещать?

а кто по вашему его вообще туда сегодня помещает?

компилятор.
ваш К.О.


вам осталось осознать,
что vtbl в dll
и vtbl в итоговом exe
абсолютно обратно совместимы.
потому и проблем никаких.

[_Bers]

у него уже нет доступа (исходников) к тому внутреннему классу.

компиляторам сегодня никто не мешает генерировать всякие таблицы импорта.
считаете есть какая то причина,
из-за которой они не смогут внести в них данные о vtbl импортируемых классов?

[Old]

вам осталось осознать,
что vtbl в dll
и vtbl в итоговом exe
абсолютно обратно совместимы.
потому и проблем никаких.

Вам осталось осознать, что патчить или подменять таблицы пока некому.
Учить загрузчик таким чудесам - глупо, учить компилятор генерить код для загрузки dll и коррекции vtbl - тоже.
Можно конечно пойти по пути Go и генерировать один бинарный блоб содержащий все-все-все...
А так, можно сделать все...

[ViTech]

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

Вот так прям все заголовки и доступны . Я может тоже за опенсорс, но скажите какому-нибудь Microsoft, чтобы они к своим библиотекам прилагали заголовки с определением для всех внутренних классов, а не только для тех, которые они посчитали нужным вынести в интерфейс библиотеки.

компиляторам сегодня никто не мешает генерировать всякие таблицы импорта.
считаете есть какая то причина,
из-за которой они не смогут внести в них данные о vtbl импортируемых классов?

При чём тут таблицы импорта? Ну добавит компилятор в приложении в vtbl новый указатель на метод, только код для этого метода он откуда возьмёт?  Одну из причины Вы уже озвучили: "ххх руководит бизнес". Её уже достаточно, чтобы скрывать реализацию в бинарниках. А в заголовках выдавать лишь необходимый минимум.

[Old]

Вот так прям все заголовки и доступны . Я может тоже за опенсорс, но скажите какому-нибудь Microsoft, чтобы они к своим библиотекам прилагали заголовки с определением для всех внутренних классов, а не только для тех, которые они посчитали нужным вынести в интерфейс библиотеки.

ViTech, достаточно будет вытащить vtbl всех классов из dll, пропатчить их с учетом новых методов и подменить адреса таблиц для классов из dll в памяти процесса.
Но кто это будет делать не понятно? Тут нужны знания и компилятора и загрузчика процессов ОС.