Здравствуйте, netch80, Вы писали:

EP>>Вообще-то это другое, с другими свойствами. final/sealed не делает метод не виртуальным, точнее виртуальный метод вполне может быть final
EP>>И кстати final есть и в C++, что я уже выше упоминал.
N>Формально и в C++ ничто не мешает сделать все методы виртуальными, насколько я помню. Но не делают

Зачем?

N>Я про то, что если метод не существовал у предков и сразу был объявлен final, то этого достаточно, чтобы его не виртуализовать

Даже если он существовал у предков, но в наследнике помечен как final И вызов этого метода идёт именно через наследника — то и в таком случае этого достаточно для прямого вызова

N>и главное, что это общеизвестно и активно используется. И если собеседник этого не знает, но говорит, что "все методы являются виртуальными функциями", то он просто не готов для дискуссии.
N>А формальности оставьте для language lawyers.

И формально и неформально final не применим к обсуждаемому примеру

N>>>Это чуть упрощая (есть проблемы одноимённых методов и т.п.), но для данных целей сгодится. И видя final — компилятор (пусть JIT) точно так же имеет право рисовать обращение напрямую к нужному методу или инлайнить его.
EP>>Вот только в примере

Автор: pilgrim_
Дата: 14.01.17

который разбирался в топике, final в базе A на метод f не поставишь
N>Не поставишь. Но компилятор уже знает, что тип зависит от , и вполне может внутри себя сделать (псевдокод)
N>

N>A a;
N>if (x) { a = new B(); a.B::f(); }
N>else { a = new C(); a.C::f(); }
N>

Я говорю про пример:

A a;
// ...
a.f();

компиляторы C++ делают прямой вызов, даже если f виртуальный и НЕ final.
О таком примере alex_public говорил изначально:

_>но и для виртуальных компилятор гарантированно осуществляет инлайнинг, если они вызваны от обычной переменной (а не от указателя или ссылки).