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

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

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

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

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

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

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

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

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

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

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




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

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

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

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


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

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


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

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

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


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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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