Russian Qt Forum

Добрый день

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

Спасибо

Потому что нельзя сформировать vtbl для бесконечного множества вариантом шаблонного методов.

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

технических ограничений не существует.

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

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

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

Может комитет и не видит, но мне не раз приходилось делать это искусственно, заметно усложняя при этом код.

Насколько я понял, дело в следующемДа, но тут одна бяка: "инстанциация" может случиться из другой единицы трансляции (по-простому из др .cpp файла). И тогда надо что-то делать с теми файлами что уже откомпилены, как-то менять VMT классов что в них - а нынешняя технология компиляторов этого не позволяет, мол, откомпилено - значит все, готово и изменению не подлежит.

А что это?

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

Например:
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);

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

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

Компилятор может и ничего, а вот линкер мог бы и перестроить VMT(s) c учетом "прибывших"

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

единственное, я так до конца и не понял:
можно ли будет удалять/добавлять/изменять реализацию уже имеющихся классов.

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

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

но... реально, пока они там что нибудь родят ещё не мало воды утечет.
хз что у них получится. рефлексию они ещё в 17 обещали.
сейчас я даже насчет 20 не уверен)))

а пока у них только концепты/прототипы/наброски.

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

Скомпилировать новую перегрузку и адрес этой перегруженной ф-ции поместить в новый слот 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 ); 
..
};

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

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

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

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

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


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


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

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

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

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

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


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

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

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


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

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

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

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


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

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

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

все что нужно - модифицировать импортировать vtbl с учетом новеньких.
здесь нет никаких технических ограничений.

свои глупости оставьте себе.

Вам осталось осознать, что я не говорю о технических ограничениях. Повторю, сделать можно все, только почему-то не сделано.
Почему?

Ждем очередной бред.

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

ваш К. О.


какой то странный вопрос...

звучит примерно так:
- у нас есть vtbl, как нам теперь запустить метод наследника через базовый интерфейс?
- выполнить запуск по указателю в vtbl? не, не слышал.

см выше.

Так он же сам его и создает при "инстанциации" нового типа

Мда... Ну давайте разжуём про интерфейс - реализацию.

1. Библиотека.

ISomeClass.h

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

SomeConcreteClass.h

C++ (Qt)
#include <ISomeClass.h>
 
class SomeConcreteClass : public ISomeClass
{
    ...
    template <class T>
    void doSomething(T value) override
    {
         std::cout << "SomeConcreteClass  value = " << value << std::endl;
    }
}
 

SomeLibrary.h

C++ (Qt)
#include <ISomeClass.h>
 
ISomeClass * makeSomeObject();
 

SomeLibrary.cpp

C++ (Qt)
#include <SomeConcreteClass.h>
ISomeClass * makeSomeObject()
{
    return new SomeConcreteClass();
}
 

где-то во внутренностях библиотеки есть вызовы

C++ (Qt)
ISomeClass * some_object = makeSomeObject();
some_object->doSomething(int(10));
some_object->doSomething(double(5.7));
 

Библиотека компилируется, для ISomeClass/SomeConcreteClass формируется vtbl с doSomething(int) и doSomething(double()), которые ссылаются на код, сгенерированный на основе SomeConcreteClass::doSomething() из файла SomeConcreteClass.h. Получается бинарник SomeLibrary.dll, и чтобы его могли подключать, пользователям библиотеки дают заголовки SomeLibrary.h и ISomeClass.h. Файл SomeConcreteClass.h не дают.

2. Приложение.

Приложению доступны заголовки SomeLibrary.h, ISomeClass.h и бинарник SomeLibrary.dll. Разработчик создаёт объект:

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

и далее вызывает шаблонный метод с типом, которого нет в библиотеке:

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

На какой код будет ссылаться указатель в vtbl для doSomething(QWidget)? Если код должен генерироваться на основе SomeConcreteClass::doSomething(), который находится в файле SomeConcreteClass.h, которого у пользователя библиотеки физически нет.

А что там выше? :)
Заявления о отсутствии технических трудностей, так это мы и без вас знали.
АйТи область она такая... с наличием интереса все можно сделать... а с деньгами... так вообще. :)
Фича полезная, но не сделана... Комитет уже метаклассы там добавляет, а такую простую штуку сделать не могут...

А я думаю не хотят. Потому что для реализации этого, придется компилятор учить всем "премудростям" целевой платформы, о которых сейчас он понятия не имеет.

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

Тема зашла в тупик.
Им одно, они второе, им первое, они четвертое.

1) необходимость введения данной поддержки на всех платформах.
2) необходимость поддержки "старых" либ.
3) изменение структуры Dll для поддержки новых возможностей. (как следствие программы для работы со старыми dll не будут работать с новыми)
4) введение синтаксиса "разрешённых/запрещённых" виртуальных методов. (Не все хотят чтобы их классы вертели как хотели. )
5) увеличение времени компиляции/запуска/линковки всех программ.
6) как следствие из вышеперечисленного необходимо переписывать ОГРОМНЕЙШИЙ пласт программ, использующих Dll, перекомпиляция почти всех продаваемых продуктов, систем защиты dll и прочего.

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

PS ни одна компания не выделит деньги на внедрение этого нового стандарта за просто так. Нужна очень веская причина для изменения устоев.
PPS ничто не мешает вам самим написать собственный компилятор, с необходимым функционалом. И будет это не "новые dll", а плагины ваши.

Вот :). Уже варианты пошли. Вместо однообразных мантр некоторых, что "компилятор сам кода нагенерит и vtbl поправит". Сколько ещё всяких особенностей отыщется, если копнуть поглубже.

Вот и я про это.
Мы тут даже решить не можем кто все это будет делать? :) Находить библиотеки в памяти процесса, выбирать из них vtbl, расширять новыми методами, патчить процесс в памяти на новые таблицы?
Компилятор? Не слишком дофига ему придется узнать о целевой платформе, для генерации всех этих чудес.
Загрузчик? Нахрен ему все эти заморочки, связанные исключительно с плюсовыми процессами и библиотеками.

А так ограничений нет. :)

понял вопрос.
рассмотрим класс:


сам по себе шаблон-виртуал ничего не значит,
если нет инстанций.

допустим в нашей библиотечке есть класс:

C++ (Qt)
#include <ISomeClass.h>
class SomeConcreteClass : public ISomeClass
{
 
    template <class T>
    void doSomething(T value) override
    {
         std::cout << "SomeConcreteClass  value = " << value << std::endl;
    }
}
 

его реализация так же ничего не значит до тех пор,
пока нет инстанций.

но вот тут компилятор видит вызовы шаблоно-виртуалов:

C++ (Qt)
ISomeClass * some_object = makeSomeObject();
some_object->doSomething(int(10));
some_object->doSomething(double(5.7));
 

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

и такое инстанцирование аналогично тому,
как если бы мы вручную сделали:


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

сама библиотека содержит реализации самых обычных
виртуальных методов.

именно такой подход я имел ввиду,
когда выше писал:
"шаблоно-виртуал - не более чем просто сахарок,
который реализует автоматическую копипасту"

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

интересное дальше:

при компиляции итогового приложения,
компилятор видит вызов метода с ещё одним параметром:


соответственно, он инстанцирует шаблоно-виртуал под него.
для этого ему нужно расширить vtbl базового класса,
как если бы он был:


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

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

в действительности,
дизайн полиморфизма с++ с его классовой системой
просто технически не способны защитить от подобных ошибок:

http://rextester.com/LVWMK76234



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

(я только у новичков встречал, например)

просто потому, что как правило программисты - ребята достаточно здравомыслящие,
и не пишут откровенное УГ за гранью здравого смысла.

выдавать наружу интерфейс на внутреннего наследника,
содержащего шаблонно-виртуал - ССЗБ.

если в 5ти словах, то там вот это:

если не в 5ти словах - почитайте тему.

конкретный компилятор пишется под конкретную платформу вообще то.
он в курсе всех её премудростей.

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

обратная совместимость? не, не слышал.


обратная совместимость? не, не слышал.


вы это о чем?

override/final/delete вам не достаточно?
хочется чего то ещё?

это такой традиционный недостаток с++,
на которой традиционно все кладут
предварительно скомпилированный заголовок? не не слышал

на запуск шаблоны вообще никак не влияют
после компиляции никаких шаблонов уже не существует. не существует, Карл!!!


обратная совместимость? не, не слышал.

Вы, конечно, молодец, Написали много текста с комментариями типо "не слышал", но это не отменяет всей работы.
Чтобы добавить такие фичи нужен стандарт. Время + деньги.
Чтобы реализовать этот стандарт, пусть даже на простейшем mingw+msvc нужен труд десятков, если не сотен людей. Время + деньги.
Чтобы поддерживать и старые и новые либы, дабы IDE работали как надо, надо дописать все IDE. Ну штук 20 их точно есть, не учитывая непопулярные. Время + деньги.
Увеличение времени компиляции каждой либы на 0,2с ведёт к... Время + деньги. Маленькое время и маленькие деньги, но зато много либ.
И насчёт переписывания программ - я имел в виду огромнейший пласт программ, которые ИСПОЛЬЗУЮТ, АНАЛИЗИРУЮТ, ПРАВЯТ, ЗАЩИЩАЮТ функционал dll. Т.е.  добавление нового функционала, а не переписывание старого. Да даже добавление нового формата. Время + деньги.

Вот скажите, сколько людей здесь и сейчас, остро нуждаются в этой фиче?
Отвечу - разве что Igors. Ибо данный функционал можно заменить имеющимся. Было бы желание.

PS думаю всё скатилось в "а вот хочу", вместо "а вот нужно".
PPS я вот к примеру всё чаще прихожу к мнению что ООП типа "черный ящик" это тупик для программирования. Что должна быть открытость членов, данных, информации, которая открывает чрезвычайные перспективы. Но даже если я соберу сотни тысяч последователей, реализовывать данный функционал в стандарте не будут. Ибо тут не вводить надо, а ломать всё старый и делать новый стандарт. 

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

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

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

бизнесу (разработчикам IDE) как раз таки выгодно наличие новых фич.
это их хлеб, если что.

отсталые опенсорснутые IDE, не способные успешно конкурировать - не нужны

слишком притянуто за уши.

после компиляции никак шаблонов уже не существует, Карл!
однако любые новшества-фичи - хлеб разработчиков подобного софта.
(здесь все аналогично ситуации с IDE)

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

фича "шаблоно-виртуал" - это ведь по сути "возможность передачи шаблоно-типа посредством виртуального вызова"

это - type-erasure нового поколения.

становится возможной полноценная нативная динамика




термоядерными шаблонами с макросами на стероидах и при полном отсутствии автоматики?
(см boost)

расширением стека технологий? с привлечением какого нибудь Lua?
насколько дороже будет стоить разработка,
если помимо с++ программист должен будет знать ещё и Lua?
джун здесь уже не проканает.
а мидл стоит куда как подороже.

или дополнительным этапом построения?
(см IDL-компиляция)

наличие данной фичи сделало бы с++ самым быстрым и эффективным в мире компилируемым языком
с поддержкой динамики средствами самого языка.


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

хз какие там могут быть перспективы.
лазейку для УГ - да, открывает.


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

Нет, не в курсе.
Сейчас, компилятор генерирует код, который (внезапно!) получит управление уже после того, как Волшебная фея (загрузчик) полностью подготовит адресное пространство процесса. Загрузит куда надо динамические библиотеки, настроит все адреса и выполнит кучу важных дел. Коду приложения ни о чем беспокоится не нужно вообще.
А для коррекции vtbl, компилятор должен генерить другой код, который должен будет уметь найти в памяти процесса необходимые библиотеки, в них нужные данные, найти и подменить в коде этих библиотек адреса на новые таблицы.
А в памяти процесса остаются не все секции динамической библиотеки, служебной информации не будет. Как искать?
А если завтра поменяется загрузчик и будет формировать адресное пространство процесса по другому? Сейчас проблем нет, а с "новым компилятором" процессы перестанут запускаться.

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

с жосиси и этими вашими шлангами аналогично, да?


эпичный такой бред.



человек язык не перепутал?

конечно коду приложения не о чем беспокоится.
ведь до компиляции он - обычные текстовые буковки.
а после компиляции компилятор (внезапно!) уже как бе и не при делах вовсе,
такие дела.

другое дело - библиотеки импорта.
обычные *.lib для загрузки *.dll в режиме "без геммороя".

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

и о боже! они знают!
они догадались!
что не в астрале работают!
вот гады...

я канечн понимаю, что компиляторы никакие адреса ни в каких dll ни для каких процессов не ищут.
не их это как бе работа.

но инструментарию, которое такое умеет - сто лет в обед
DepencyWalker например.
ну просто неипеческий сложный стафф.

о да, подхачить vtbl - это такая непосильная задача, шо шандец.
это ж блин! код писать придется однако!

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

обратная совместимость? не, не слышал.

Понятно, академический программист на C++ в очередной раз написал кучу бреда, так сказать не вдаваясь в подробности... Как там все это работает, да кому оно надо... :)

Весь этот поток сознания комментировать, у меня не хватит сил, не буду.
Но по секрету академическому программисту сказу, что обычные *.lib никогда обычные *.dll не грузили, что с геммороем, что без. Не для этого они нужны. :)

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

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

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

"Компилятор пишется под конкретную платформу" и "компилятор генерирует код приложения завязанный на тонкости конкретной платформы" разные вещи. Или для вас нет?
Сейчас, компилятры генерят код приложения, который понятия не имеет про dll, как их загружать, как настраивать. А "новый компилятор" вынужден будет генерить код приложения с учетом всех тонкостей платформы.
Я это уже третий раз пишу, по моему. Если это не понятно, ну что - забейте. Какая разница, что там генерируется, главное окошко на экране появляется.

По поводу "обычных библиотек импорта".
У gcc есть такая утилитка objdump (не знаю про всякие VS, но в поставке mingw она тоже есть). Попробуйте с ее помощью дезассемблировать такую библиотеку:
objdump -d mylib.lib
и посмотрите что в ней находиться, сколько и какого там кода. :)
И если не сообразите, для чего она нужна, приходите сюда, я вам на пальцах объясню, для чего она и как работает механизм линковки с dll в венде.

Не уловил Вашей мысли. Будут созданы 2 VMT (одна для ISomeClass, другая для SomeConcreteClass). Если SomeConcreteClass не дают - ну он никаким боком и не участвует

С какой же стати "на основе SomeConcreteClass"  ???

Как же не участвуют, а на основании чего компилятор с генерирует код:

C++ (Qt)
class SomeConcreteClass : public ISomeClass
{
    void doSomething(Widget *value) override
    {
         std::cout << "SomeConcreteClass  value = " << value << std::endl;
    }
}
 

Обратите внимание, мы не наследуемся, мы используем уже определенный метод.

Вообще, хороший вопрос был.
Допустим, в длл-ке у нас живет SomeConcreteClass, для которого инстанциирован шаблон с int:

SomeConcreteClass *s1;
...
s1->doSomething<int>(123);

то есть в vtbl при загрузке длл в приложение у нас имеется указатель на
SomeConcreteClass::doSomething(int value);

И вот мы где-то в программе делаем SomeConcreteClass *s2, для которого инстанцируем с QWidget:
s2->doSomething<QWidget*>(myWidget);

теперь у нас в vtbl что? по идее два вхождения
SomeConcreteClass::doSomething(int value);
SomeConcreteClass::doSomething(QWidget* value);

или же компиль должен послать в лес, т.к. в длл не было никакого QWidget?
Но ведь в момент сборки приложения это еще не известно.
Поэтому каким то образом vtbl должна быть запатчена в рантайме...не?

В идеале, конечно, для дальнейшего развития языка, паттерн "Черный ящик" должен быть низложен. Так же всё идёт к изменению кода во время работы программы.
Так что да, патчинг на лету таблиц, добавление нового функционала одномоментно и так далее в будущем будет. В той или иной форме будет. Но вот через сколько лет до этого дойдёт :)

Здравствуйте, вирусы :)

Ну, вирусы тоже вымрут по идее :)
Если скрестить Windows/Linux, что в принципе и происходит, то о вирусах можно будет забыть. Хотя тем не менее, я за последние лет 5 не поймал ни одного. Хотя вроде все условия, антивируса нет, UAC отключен, сижу под админом. Ан нет, не ловится на кокос.

Откуда ты тогда знаешь, поймал или нет? Может твой комп уже в нескольких ботнетах подрабатывает? :)

Так может с внедрением возможности "изменения кода во время работы программы" они и в линухе появятся :).

Левых процессов нет, загрузки компа нет, левых "лишних" портов приложений нет, левых запросов нет.
Так что всё в порядке.

Ах да, конечно же картинок на весь экран с черными властелинами тоже нет.  

PS Так возможность уже есть то. Вон vs2016 позволяет менять куски кода в дебажной программе на лету, без перезапуска. Конечно там есть ограничения, но само направление уже работает.

на всех компьютерах ботнетов "всё в порядке". Иначе смысла нет их включать в ботнет :)

Вы неправы. На всех компах ботнета висят добрые ватчеры и ждут сигналов. И начинают жрать ресурсы по команде, слать мусор, планированно атаковать и так далее.
На деле, Windows имеет достаточно серьёзную защиту от вирусов и ботнетов. И при отсутствиии дурака за клавиатурой, она покрывает 95% вирусов и прочих неприятностей.

PS 5% остаются на дырки и уязвимости, но против этого ни одна программа не выстоит :D