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

[_Bers]

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

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

Чтобы реализовать этот стандарт, пусть даже на простейшем 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 я вот к примеру всё чаще прихожу к мнению что ООП типа "черный ящик" это тупик для программирования. Что должна быть открытость членов, данных, информации, которая открывает чрезвычайные перспективы.

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

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

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

[Old]

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

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

[_Bers]

Нет, не в курсе.

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

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


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

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

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

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

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

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

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

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

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

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

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

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

[_Bers]

А если завтра поменяется загрузчик и будет формировать адресное пространство процесса по другому?

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

[Old]

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

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

[_Bers]

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

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

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

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

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

[Old]

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

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

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

[Igors]

Библиотека компилируется, для 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" 

[Old]

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

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

Код

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

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

[Racheengel]

Вообще, хороший вопрос был.
Допустим, в длл-ке у нас живет 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 должна быть запатчена в рантайме...не?

[Bepec]

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

[kuzulis]

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

[Bepec]

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

[Alex Custov]

я за последние лет 5 не поймал ни одного. Хотя вроде все условия, антивируса нет, UAC отключен, сижу под админом.

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

[ViTech]

Ну, вирусы тоже вымрут по идее
Если скрестить Windows/Linux, что в принципе и происходит, то о вирусах можно будет забыть.

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