Форум
Компьютерные священные войны
Тема
Как правильно задавать вопросы
B
I
abc
U
X
3
X
3
H1
H2
H3
H4
H5
H6
Asm
C/C++
C#
Erlang
Haskell
IDL
Java
Lisp
MSIL
Nemerle
ObjC
OCaml
Pascal
Perl
PHP
Prolog
Python
Ruby
Rust
SQL
VB
Здравствуйте, alex_public, Вы писали: _>Здравствуйте, netch80, Вы писали: _>>>Ты же наверняка знаешь, что во всех этих языках все методы являются виртуальными функциями (говоря языком C++). N>>Вы тут ну очень много написали, но в следующих ста сообщениях я не увидел возражений, поэтому комментирую. Как это получилось, что ты не в курсе, что в Java и C# просто перевёрнуто умолчание объявления метода виртуальным? Там, где в C++ говорится virtual, в Java молчат, а где в C++ не говорится virtual, в Java говорится final (а в C# - sealed), последствия для виртуальности те же. Это чуть упрощая (есть проблемы одноимённых методов и т.п.), но для данных целей сгодится. _>Не следует путать final (кстати тоже есть в C++, как отдельная сущность) и не виртуальные функции. В отличие от последних final полностью блокирует одно из ключевых преимуществ ООП подхода - расширяемость и кастомизируемость через наследование. Так что если в своём коде ты вполне можешь позволить себе применять данную возможность, то у скажем авторов библиотек ситуация намного печальнее. _>Более того, даже если ты при кастомизации какого-нибудь библиотечного класса в своё проекте проставишь ему везде final, то в очень многих ситуациях (а именно, если этот твой класс предназначен для использования библиотекой) это вообще никак не повлияет на ситуацию, т.к. код вызова твоего класса (расположенный внутри библиотеки) всё равно будет записан через его предка. N>>И видя final - компилятор (пусть JIT) точно так же имеет право рисовать обращение напрямую к нужному методу или инлайнить его. N>>Вот если кто не пишет этот final на критически важных местах - он ССЗБ. _>Кстати, то, что компилятор имеет такое право в подобном случае, - я согласен. А вот делает ли он это в реальности? Вот конкретный стандартный компилятор java последней версии. Кто-нибудь проверял данный факт? _>>> Что это значит с точки зрения оптимизации? Что компилятор (пусть он даже очень сильный и у него есть куча времени) физически не сможет сделать инлайнинг, потому что просто не знает какой конкретно код в реальности будет вызываться - это определяется только в рантайме. В то время как в C++ не только часто употребимы не виртуальные функции, но и для виртуальных компилятор гарантированно осуществляет инлайнинг, если они вызваны от обычной переменной (а не от указателя или ссылки). N>>И в Java это есть. Кто-то из оракловцев показывал в примерах JIT оптимизации, как компилятор, зная тип, подставлял вызов конкретного метода при работе через ссылку на базовый интерфейс. _>Нет, этого нет, потому что физически невозможно (собственно в Java нельзя гарантированно "знать тип" объекта по его объявлению - там без проблем может прятаться какой-то из наследников объявленного, причём чаще всего полученный из какой-то внешней функции). _>Насколько я помню некоторые презентации Java по оптимизации, там были упоминанию о некоторых оптимизациях в данной области. Но речь там шла о скорее статистических методах (некий аналог escape анализа), которые срабатывают в редких случаях и после длительного наблюдения за исполнением кода. Думаю не надо объяснять, чем подобное отличается от гарантированного прямого вызова на уровне синтаксиса языка? )
Теги:
Введите теги разделенные пробелами. Обрамляйте в кавычки словосочетания с пробелами внутри, например:
"Visual Studio" .NET
Имя, пароль:
Загрузить
Нравится наш сайт?
Помогите его развитию!
Отключить смайлики
Получать ответы по e-mail
Проверить правописание
Параметры проверки …