Russian Qt Forum

Программирование => С/C++ => Тема начата: Igors от Сентябрь 01, 2017, 11:04



Название: Шаблонный виртуал
Отправлено: Igors от Сентябрь 01, 2017, 11:04
Добрый день

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

Спасибо


Название: Re: Шаблонный виртуал
Отправлено: Old от Сентябрь 01, 2017, 11:55
Потому что нельзя сформировать vtbl для бесконечного множества вариантом шаблонного методов.


Название: Re: Шаблонный виртуал
Отправлено: Alex Custov от Сентябрь 01, 2017, 15:03
Потому что нельзя сформировать vtbl для бесконечного множества вариантом шаблонного методов.

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


Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 01, 2017, 23:55
Добрый день

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

Спасибо

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



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

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

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

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


Название: Re: Шаблонный виртуал
Отправлено: Igors от Сентябрь 02, 2017, 05:29
..видимо комитет не видит в ней надобности.
Может комитет и не видит, но мне не раз приходилось делать это искусственно, заметно усложняя при этом код.

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

они на с++20 анонсировали статическую рефлексию.
А что это?


Название: Re: Шаблонный виртуал
Отправлено: ViTech от Сентябрь 02, 2017, 11:36
Про "бесконечности ведь нет", "технических ограничений не существует" и "все верно кроме "фичу слишком сложно реализовать"" как-то я сомневаюсь. С библиотеками тоже сложностей нет?

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

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

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


Название: Re: Шаблонный виртуал
Отправлено: Igors от Сентябрь 02, 2017, 12:10
Что должен сделать компилятор?
Компилятор может и ничего, а вот линкер мог бы и перестроить VMT(s) c учетом "прибывших"


Название: Re: Шаблонный виртуал
Отправлено: Old от Сентябрь 02, 2017, 12:45
Компилятор может и ничего, а вот линкер мог бы и перестроить VMT(s) c учетом "прибывших"
В динамической библиотеке? :)


Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 02, 2017, 16:41
Про "бесконечности ведь нет", "технических ограничений не существует" и "все верно кроме "фичу слишком сложно реализовать"" как-то я сомневаюсь. С библиотеками тоже сложностей нет?

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

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

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

в какой то момент он знает про int и double,
на этот момент он инстанцировал:
Код:
virtual void doSomething(int  value);
virtual void doSomething(double value);
увидев запись:
Код:
some_object->doSomething(widget);

он просто инстанцирует ещё одну перегрузку:
Код:
virtual void doSomething(QWidget * value);

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

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



Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 02, 2017, 17:05
тут одна бяка: "инстанциация" может случиться из другой единицы трансляции (по-простому из др .cpp файла).

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

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

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

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

Код:
struct sample{
    static int val;  //где то в sample.cpp:  int sample::val = 33;
};

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

Код:
template<class T>
struct sample{
    static int val;  
};
int sample<T>::val = 33; //<--- в какой именно ед. трансляции он будет жить?

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

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

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

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

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

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

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

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



Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 02, 2017, 17:19
они на с++20 анонсировали статическую рефлексию.
А что это?

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

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

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

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

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

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

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


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


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


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


Название: Re: Шаблонный виртуал
Отправлено: Bepec от Сентябрь 02, 2017, 21:59
Тогда это нарушает весь текущий принцип dll. Тем самым давая такие просторы для багов/некорретных использований и переборов, что компиляция будет минут по 20 длиться простенькой dll.

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


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


Название: Re: Шаблонный виртуал
Отправлено: __Heaven__ от Сентябрь 02, 2017, 23:22
Old, а без наличия шаблонов при наследовании от класса из библиотеки мы же можем добавлять новые виртуальные методы... Получается таблица расширяется?


Название: Re: Шаблонный виртуал
Отправлено: Old от Сентябрь 02, 2017, 23:25
Old, а без наличия шаблонов при наследовании от класса из библиотеки мы же можем добавлять новые виртуальные методы... Получается таблица расширяется?
Таблица своя на каждый класс. Расширяется таблица нового класса наследника, таблица базового класса не меняется.


Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 03, 2017, 03:32
Тогда это нарушает весь текущий принцип dll. Тем самым давая такие просторы для багов/некорретных использований и переборов, что компиляция будет минут по 20 длиться простенькой dll.

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

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

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

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


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


Название: Re: Шаблонный виртуал
Отправлено: Igors от Сентябрь 03, 2017, 09:25
vtbl на стороне приложения была модифицирована с учетом "новеньких".
Да, именно это я имел ввиду

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


Название: Re: Шаблонный виртуал
Отправлено: ViTech от Сентябрь 03, 2017, 13:29
для шаблонов нет никаких "общих случаев, когда не известно с чем шаблон был инстанцирован".
есть единственный случай, когда компилятор знает точно для каких типов был инстанцирован шаблон.

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


Название: Re: Шаблонный виртуал
Отправлено: Igors от Сентябрь 03, 2017, 15:09
И опять тот же вопрос: "Что должен сделать компилятор?", когда в приложении увидит новую перегрузку для 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 );
..
};
Ну как-то не солидон  :'(


Название: Re: Шаблонный виртуал
Отправлено: Old от Сентябрь 03, 2017, 15:22
Скомпилировать новую перегрузку и адрес этой перегруженной ф-ции поместить в новый слот VMT.
Если бы все было так просто. :) А в vtbl всех базовых классов этот адрес кто будет помещать?
Должна остаться возможность вызывать этот метод через указатель на объект базового класса.


Название: Re: Шаблонный виртуал
Отправлено: ViTech от Сентябрь 03, 2017, 15:39
Скомпилировать новую перегрузку и адрес этой перегруженной ф-ции поместить в новый слот VMT. Под "копипастой" (как я понял) подразумевается как это делается сейчас.
Акцент на том, что речь идёт о чистом виртуальном методе. В общем случае, когда объявление (declaration) сигнатуры есть, а определения (definition)/тела метода нет. Когда компилятор собирает библиотеку, у него есть исходники класса, который реализует интерфейс, и он может собрать библиотеку. Когда же компилятор собирает приложение с той библиотекой, у него уже нет доступа (исходников) к тому внутреннему классу. Поэтому и спрашивал, откуда компилятор будет брать код, чтобы "доинстанцировать" методы, появившиеся в приложении для того конкретного внутреннего класса библиотеки :).


Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 03, 2017, 15:42

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

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

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

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

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

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

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

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

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

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

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


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




Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 03, 2017, 15:44
А в vtbl всех базовых классов этот адрес кто будет помещать?

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

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


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





Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 03, 2017, 15:49
у него уже нет доступа (исходников) к тому внутреннему классу.

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


Название: Re: Шаблонный виртуал
Отправлено: Old от Сентябрь 03, 2017, 15:55
вам осталось осознать,
что vtbl в dll
и vtbl в итоговом exe
абсолютно обратно совместимы.
потому и проблем никаких.
Вам осталось осознать, что патчить или подменять таблицы пока некому.
Учить загрузчик таким чудесам - глупо, учить компилятор генерить код для загрузки dll и коррекции vtbl - тоже.
Можно конечно пойти по пути Go и генерировать один бинарный блоб содержащий все-все-все...
А так, можно сделать все...


Название: Re: Шаблонный виртуал
Отправлено: ViTech от Сентябрь 03, 2017, 15:57
компилятору доступны заголовки.
это все, что ему нужно,
что бы сгенерировать код корректного импорта vtbl из dll,
и модифицировать таблицу с учетом новеньких.

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

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

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


Название: Re: Шаблонный виртуал
Отправлено: Old от Сентябрь 03, 2017, 16:06
Вот так прям все заголовки и доступны :). Я может тоже за опенсорс, но скажите какому-нибудь Microsoft, чтобы они к своим библиотекам прилагали заголовки с определением для всех внутренних классов, а не только для тех, которые они посчитали нужным вынести в интерфейс библиотеки.
ViTech, достаточно будет вытащить vtbl всех классов из dll, пропатчить их с учетом новых методов и подменить адреса таблиц для классов из dll в памяти процесса.
Но кто это будет делать не понятно? Тут нужны знания и компилятора и загрузчика процессов ОС.


Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 03, 2017, 16:11
вам осталось осознать,
что vtbl в dll
и vtbl в итоговом exe
абсолютно обратно совместимы.
потому и проблем никаких.
Вам осталось осознать, что патчить или подменять таблицы пока некому.
Учить загрузчик таким чудесам - глупо, учить компилятор генерить код для загрузки dll и коррекции vtbl - тоже.
Можно конечно пойти по пути Go и генерировать один бинарный блоб содержащий все-все-все...
А так, можно сделать все...

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

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

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


Название: Re: Шаблонный виртуал
Отправлено: Old от Сентябрь 03, 2017, 16:15
вам осталось осознать, что таблицы импорта уже существуют.
загрузчики умеют их грузить.
а компиляторы умеют генерить код для загрузки dll.

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

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

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

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


Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 03, 2017, 16:21
Вот так прям все заголовки и доступны
если приложению не доступен заголовок ISomeClass,
значит на стороне приложения вы не сможете от него наследоваться,
и заюзать шаблоно-виртуал.

ваш К. О.

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

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

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


Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 03, 2017, 16:21
Вам осталось осознать, что я не говорю о технических ограничениях. Повторю, сделать можно все, только почему-то не сделано.
Почему?

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

см выше.


Название: Re: Шаблонный виртуал
Отправлено: Igors от Сентябрь 03, 2017, 16:52
Ну добавит компилятор в приложении в vtbl новый указатель на метод, только код для этого метода он откуда возьмёт? 
Так он же сам его и создает при "инстанциации" нового типа


Название: Re: Шаблонный виртуал
Отправлено: ViTech от Сентябрь 03, 2017, 16:57
если приложению не доступен заголовок ISomeClass,
значит на стороне приложения вы не сможете от него наследоваться,
и заюзать шаблоно-виртуал.

ваш К. О.

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

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

звучит примерно так:
- у нас есть 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, которого у пользователя библиотеки физически нет.


Название: Re: Шаблонный виртуал
Отправлено: Old от Сентябрь 03, 2017, 17:02
см выше.
А что там выше? :)
Заявления о отсутствии технических трудностей, так это мы и без вас знали.
АйТи область она такая... с наличием интереса все можно сделать... а с деньгами... так вообще. :)
Фича полезная, но не сделана... Комитет уже метаклассы там добавляет, а такую простую штуку сделать не могут...

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



Название: Re: Шаблонный виртуал
Отправлено: Old от Сентябрь 03, 2017, 17:20
На какой код будет ссылаться указатель в vtbl для doSomething(QWidget)? Если код должен генерироваться на основе SomeConcreteClass::doSomething(), который находится в файле SomeConcreteClass.h, которого у пользователя библиотеки физически нет.
В данном случае компилятору придется не метод генерировать, а ошибку компиляции. Вызывать можно будет только те методы, инстанции которых были определены.


Название: Re: Шаблонный виртуал
Отправлено: Bepec от Сентябрь 03, 2017, 18:25
Тема зашла в тупик.
Им одно, они второе, им первое, они четвертое.

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

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

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


Название: Re: Шаблонный виртуал
Отправлено: ViTech от Сентябрь 03, 2017, 18:28
В данном случае компилятору придется не метод генерировать, а ошибку компиляции. Вызывать можно будет только те методы, инстанции которых были определены.

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


Название: Re: Шаблонный виртуал
Отправлено: Old от Сентябрь 03, 2017, 18:38
Сколько ещё всяких особенностей отыщется, если копнуть поглубже.
Вот и я про это.
Мы тут даже решить не можем кто все это будет делать? :) Находить библиотеки в памяти процесса, выбирать из них vtbl, расширять новыми методами, патчить процесс в памяти на новые таблицы?
Компилятор? Не слишком дофига ему придется узнать о целевой платформе, для генерации всех этих чудес.
Загрузчик? Нахрен ему все эти заморочки, связанные исключительно с плюсовыми процессами и библиотеками.

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


Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 03, 2017, 23:43
Мда... Ну давайте разжуём про интерфейс - реализацию.

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

Код:
class ISomeClass
{
    template <class T>
    virtual void doSomething(T value) = 0;
}

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

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

Код
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));
 

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

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

Код:
class ISomeClass
{
    virtual void doSomething(int value) = 0;
    virtual void doSomething(double value) = 0;
}

class SomeConcreteClass : public ISomeClass
{
    void doSomething(int value) override
    {
         std::cout << "SomeConcreteClass  value = " << value << std::endl;
    }
    void doSomething(double value) override
    {
         std::cout << "SomeConcreteClass  value = " << value << std::endl;
    }
}

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

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

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

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

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

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

Код:
some_object->doSomething(new QWidget());

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

Код:
class ISomeClass
{
    virtual void doSomething(int value) = 0;
    virtual void doSomething(double value) = 0;
    virtual void doSomething(QWidget* value) = 0;
}

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

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

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

http://rextester.com/LVWMK76234

Код:
#include <iostream>

struct base
{
    virtual void doSomething(int value) = 0;
   
    base* sample = nullptr; // <--- regular in real code
};


struct concrete: base
{
    ~concrete()
    {
        sample->doSomething(10); // <--- upps
    }
   
};

struct der: concrete
{
    der()
    {
        this->sample = this; // bomb
    }
   
    virtual void doSomething(int value)
    {
        std::cout <<"doSomething("<<value<<")\n";
    }
};

int main()
{
    der d;  //<--- babah!!!
}


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

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

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

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





Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 03, 2017, 23:49
А что там выше? :)

если в 5ти словах, то там вот это:
А я думаю не хотят.

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

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







Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 04, 2017, 00:00
1) необходимость введения данной поддержки на всех платформах.
такой необходимости никогда не существовало.
на практике разные компиляторы в разной степени
поддерживают стандарт.

2) необходимость поддержки "старых" либ.
обратная совместимость? не, не слышал.


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


4) введение синтаксиса "разрешённых/запрещённых" виртуальных методов. (Не все хотят чтобы их классы вертели как хотели. )
вы это о чем?

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

5) увеличение времени компиляции/запуска/линковки всех программ.
это такой традиционный недостаток с++,
на которой традиционно все кладут
предварительно скомпилированный заголовок? не не слышал

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


6) как следствие из вышеперечисленного необходимо переписывать ОГРОМНЕЙШИЙ пласт программ, использующих Dll, перекомпиляция почти всех продаваемых продуктов, систем защиты dll и прочего.
обратная совместимость? не, не слышал.


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

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

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



Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 04, 2017, 03:47
Вы, конечно, молодец, Написали много текста с комментариями типо "не слышал", но это не отменяет всей работы.
Чтобы добавить такие фичи нужен стандарт. Время + деньги.
комитет - не общество благотворительности.
люди работают за деньги.
они будут продолжать получать свою зп вне зависимости от того,
какая именно фича будет, или не будет добавлена в стандарт.

Чтобы реализовать этот стандарт, пусть даже на простейшем mingw+msvc нужен труд десятков, если не сотен людей. Время + деньги.
см выше, моё сообщение,
где я упомянул идеому "программирование через страдание".

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

Чтобы поддерживать и старые и новые либы, дабы IDE работали как надо, надо дописать все IDE. Ну штук 20 их точно есть, не учитывая непопулярные. Время + деньги.
бизнесу (разработчикам IDE) как раз таки выгодно наличие новых фич.
это их хлеб, если что.

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

Увеличение времени компиляции каждой либы на 0,2с ведёт к... Время + деньги. Маленькое время и маленькие деньги, но зато много либ.
слишком притянуто за уши.

И насчёт переписывания программ - я имел в виду огромнейший пласт программ, которые ИСПОЛЬЗУЮТ, АНАЛИЗИРУЮТ, ПРАВЯТ, ЗАЩИЩАЮТ функционал dll. Т.е.  добавление нового функционала, а не переписывание старого. Да даже добавление нового формата. Время + деньги.
после компиляции никак шаблонов уже не существует, Карл!
однако любые новшества-фичи - хлеб разработчиков подобного софта.
(здесь все аналогично ситуации с IDE)

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

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

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

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

Код:
#define OUT_TO_STREAM(classType)   \
    template<class ostream>friend  \
        ostream& operator<<(ostream& os, const classType& obj )

struct some
{
    OUT_TO_STREAM(some) { return os << "sample\n"; }
};

std::any a(some);  

// подобное на практике нужно сплошь и рядом
// попробуйте реализовать без шаблоно-виртуала
std::cout << a << std::endl;  
someOut << a << std::endl;

std::any a(some1);  
std::any b(some2);  

a + b; // автоматический вывод шаблоно типов: some1 + some2


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

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

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

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

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


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

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

Но даже если я соберу сотни тысяч последователей, реализовывать данный функционал в стандарте не будут. Ибо тут не вводить надо, а ломать всё старый и делать новый стандарт.  

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


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


Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 04, 2017, 08:22
Нет, не в курсе.

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

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


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


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

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

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

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

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

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

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

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

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

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



Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 04, 2017, 08:26
А если завтра поменяется загрузчик и будет формировать адресное пространство процесса по другому?

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


Название: Re: Шаблонный виртуал
Отправлено: Old от Сентябрь 04, 2017, 08:38
Понятно, академический программист на C++ в очередной раз написал кучу бреда, так сказать не вдаваясь в подробности... Как там все это работает, да кому оно надо... :)

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



Название: Re: Шаблонный виртуал
Отправлено: _Bers от Сентябрь 04, 2017, 08:47
Понятно, академический программист на C++ в очередной раз написал кучу бреда, так сказать не вдаваясь в подробности... Как там все это работает, да кому оно надо... :)

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

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

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

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




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

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


Название: Re: Шаблонный виртуал
Отправлено: Igors от Сентябрь 04, 2017, 10:07
Библиотека компилируется, для ISomeClass/SomeConcreteClass формируется vtbl с doSomething(int) и doSomething(double()), которые ссылаются на код, сгенерированный на основе SomeConcreteClass::doSomething() из файла SomeConcreteClass.h. Получается бинарник SomeLibrary.dll, и чтобы его могли подключать, пользователям библиотеки дают заголовки SomeLibrary.h и ISomeClass.h. Файл SomeConcreteClass.h не дают.
Не уловил Вашей мысли. Будут созданы 2 VMT (одна для ISomeClass, другая для SomeConcreteClass). Если SomeConcreteClass не дают - ну он никаким боком и не участвует

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


Название: Re: Шаблонный виртуал
Отправлено: Old от Сентябрь 04, 2017, 10:12
Не уловил Вашей мысли. Будут созданы 2 VMT (одна для ISomeClass, другая для SomeConcreteClass). Если SomeConcreteClass не дают - ну он никаким боком и не участвует
Как же не участвуют, а на основании чего компилятор с генерирует код:
Код
C++ (Qt)
class SomeConcreteClass : public ISomeClass
{
   void doSomething(Widget *value) override
   {
        std::cout << "SomeConcreteClass  value = " << value << std::endl;
   }
}
 
Обратите внимание, мы не наследуемся, мы используем уже определенный метод.


Название: Re: Шаблонный виртуал
Отправлено: Racheengel от Сентябрь 06, 2017, 01:57
Вообще, хороший вопрос был.
Допустим, в длл-ке у нас живет 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 должна быть запатчена в рантайме...не?


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


Название: Re: Шаблонный виртуал
Отправлено: kuzulis от Сентябрь 06, 2017, 08:54
Здравствуйте, вирусы :)


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


Название: Re: Шаблонный виртуал
Отправлено: Alex Custov от Сентябрь 06, 2017, 11:46
я за последние лет 5 не поймал ни одного. Хотя вроде все условия, антивируса нет, UAC отключен, сижу под админом.

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


Название: Re: Шаблонный виртуал
Отправлено: ViTech от Сентябрь 06, 2017, 14:47
Ну, вирусы тоже вымрут по идее :)
Если скрестить Windows/Linux, что в принципе и происходит, то о вирусах можно будет забыть.

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


Название: Re: Шаблонный виртуал
Отправлено: Bepec от Сентябрь 06, 2017, 14:59
Левых процессов нет, загрузки компа нет, левых "лишних" портов приложений нет, левых запросов нет.
Так что всё в порядке.

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

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


Название: Re: Шаблонный виртуал
Отправлено: Alex Custov от Сентябрь 07, 2017, 16:07
Левых процессов нет, загрузки компа нет, левых "лишних" портов приложений нет, левых запросов нет.
Так что всё в порядке.

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


Название: Re: Шаблонный виртуал
Отправлено: Bepec от Сентябрь 07, 2017, 19:36
Вы неправы. На всех компах ботнета висят добрые ватчеры и ждут сигналов. И начинают жрать ресурсы по команде, слать мусор, планированно атаковать и так далее.
На деле, Windows имеет достаточно серьёзную защиту от вирусов и ботнетов. И при отсутствиии дурака за клавиатурой, она покрывает 95% вирусов и прочих неприятностей.

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