ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / Виртуальные методы
48 сообщений из 48, показаны все 2 страниц
  все  
Виртуальные методы
    #39846699
Фотография ЕвгенийВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЕвгенийВ
Участник
Приветствую. Чисто спортивный интерес.
Положим был базовой класс библиотеки, вообще говоря сторонней.
И мой, унаследованный от него.
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
public class Base {
    //появился в новой версии
    public void M1()
    {}
    public void M2()
    {
        M1();
    }
    
}


Код: java
1.
2.
3.
4.
5.
6.
7.
8.
public class MyClass extends Base
{
    //этот был давно
    public void M1()
    {
    }

}


В моем классе был метод M1 со своей логикой. Обновили используемую библиотеку и в ней в базовом классе тоже появился M1.
Такой код
Код: java
1.
2.
Base b = new MyClass();
       b.M2();


По идее внутри M2 дернет MyClass.M1 ?
...
Рейтинг: 0 / 0
08.08.2019, 00:00
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846759
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
ЕвгенийВ,
Ты накрутил слов про либы и библиотеки чтобы запутать?
Ты сменил код либы и тебе её надо перекомпилить.
Итого либа изменилась, а не осталась прежней.
Выходит полный ребилд всего и вся.
Задачка на два класса без всяких "было" и "стало".
Так?
...
Рейтинг: 0 / 0
08.08.2019, 08:45
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846766
Фотография ЕвгенийВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЕвгенийВ
Участник
PetroNotC Sharp,
1. Оно же позволит перекомпилировать?
2. Вызываться будет метод M1 наследника?
...
Рейтинг: 0 / 0
08.08.2019, 08:58
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846772
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
ЕвгенийВ,
Сначала компилится либа с базовым. Потом охватывающий код main
2. Получаем:

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
Base b = new MyClass();
       b.M2();

public class MyClass extends Base
{
    public void M1()
    {
    }
}
public class Base {
    public void M1()
    {}
    public void M2()
    {
        M1();
    } 
}


Да
...
Рейтинг: 0 / 0
08.08.2019, 09:13
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846776
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
ЕвгенийВпозволитда. Но тогда вопрос. Какая разница что было раньше в коде если полный ребилд всего и вся?
...
Рейтинг: 0 / 0
08.08.2019, 09:18
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846810
Фотография ЕвгенийВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЕвгенийВ
Участник
Тогда это источник трудноуловимой ошибки, ибо метод M1 в базовом классе, может делать совсем не то, что в наследнике.
...
Рейтинг: 0 / 0
08.08.2019, 10:32
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846811
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
забыл ник
Участник
ЕвгенийВТогда это источник трудноуловимой ошибки, ибо метод M1 в базовом классе, может делать совсем не то, что в наследнике.
Именно поэтому наследование говно, хотя нет - ООП в целом говно.
А твой пример это классическая буква O в SOLID принципах. Можешь почитать тут например
...
Рейтинг: 0 / 0
08.08.2019, 10:38
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846818
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
ЕвгенийВ,
Когда прогер расширяет наследника методом дайДолжников()
не посмотрев что в базом он уже есть, то это диагноз.
...
Рейтинг: 0 / 0
08.08.2019, 10:49
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846820
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
ЕвгенийВ,
Как у вас в шарпе всё интересно.
Может твой вопрос про j#?
...
Рейтинг: 0 / 0
08.08.2019, 10:50
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846823
Фотография ЕвгенийВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЕвгенийВ
Участник
PetroNotC SharpЕвгенийВ,
Когда прогер расширяет наследника методом дайДолжников()
не посмотрев что в базом он уже есть, то это диагноз.
В базовом такой метод может появиться позже.
...
Рейтинг: 0 / 0
08.08.2019, 10:58
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846824
Фотография ЕвгенийВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЕвгенийВ
Участник
PetroNotC SharpЕвгенийВ,
Как у вас в шарпе всё интересно.
Может твой вопрос про j#?
В великом и могучем C# не все методы виртуальные, если хочешь сделать это сознательно, помечаешь модификатором virtual.
...
Рейтинг: 0 / 0
08.08.2019, 10:59
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846830
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
забыл ник
Участник
ЕвгенийВPetroNotC SharpЕвгенийВ,
Когда прогер расширяет наследника методом дайДолжников()
не посмотрев что в базом он уже есть, то это диагноз.
В базовом такой метод может появиться позже.

Предпочитайте делегацию наследованию(с)
...
Рейтинг: 0 / 0
08.08.2019, 11:08
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846834
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
ЕвгенийВPetroNotC SharpЕвгенийВ,
Когда прогер расширяет наследника методом дайДолжников()
не посмотрев что в базом он уже есть, то это диагноз.
В базовом такой метод может появиться позже.опять логика от шарпа?
ПОЗЖЕ означает что прогер не смотрит что ли?
Я лично всю цепочку смотрю. Как жених смотрит тёщу делая предложение))) :)
...
Рейтинг: 0 / 0
08.08.2019, 11:13
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846837
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
ЕвгенийВ,
Аааа... вспомнил.
Ты опять про развитие базовой библиотеки либы если код вызова уже написан. Так что ли?
...
Рейтинг: 0 / 0
08.08.2019, 11:15
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846840
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
ЕвгенийВВ великом и могучема в java такое в практике просто не актуально. Когда родители испортят жизнь детям)
...
Рейтинг: 0 / 0
08.08.2019, 11:18
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846847
betelgeizex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
betelgeizex
Гость
ЕвгенийВТогда это источник трудноуловимой ошибки, ибо метод M1 в базовом классе, может делать совсем не то, что в наследнике.

Не такой уж и трудноуловимой, если использовать анализаторы типа Sonar (а их надо использовать всегда):

Код: plaintext
1.
2.
3.
"@Override" should be used on overriding and implementing methods
 
Code smell Major
...
Рейтинг: 0 / 0
08.08.2019, 11:21
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846853
Фотография ЕвгенийВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЕвгенийВ
Участник
betelgeizexЕвгенийВТогда это источник трудноуловимой ошибки, ибо метод M1 в базовом классе, может делать совсем не то, что в наследнике.

Не такой уж и трудноуловимой, если использовать анализаторы типа Sonar (а их надо использовать всегда):

Код: plaintext
1.
2.
3.
"@Override" should be used on overriding and implementing methods
 
Code smell Major

Короче, ситуация имеет место быть?

Анализаторы хорошо, но если это какой нибудь админ обновляет что то и не в зуб ногой про анализаторы?
...
Рейтинг: 0 / 0
08.08.2019, 11:27
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846863
betelgeizex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
betelgeizex
Гость
ЕвгенийВ],

А вообще, для чего вы наследуетeсь от класса Base? Видимо для того, чтобы наследовать поведение базового класса, правильно?

Поведение класса Base состоит в том, чтобы из метода М2 вызывать М1, при этом предполагается, что M1 может быть перекрыт в наследниках (иначе автор класса пометил бы M1 как 'final')

Переопределяя (overload aka 'new') метод M1, вы тем самым ломаете вышеописанное поведение базового класса в наследнике. Это про 'L' в SOLID.


А вообще всё ООП - источник трудноуловимых ошибок
...
Рейтинг: 0 / 0
08.08.2019, 11:37
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846867
betelgeizex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
betelgeizex
Гость
ЕвгенийВ...
Короче, ситуация имеет место быть?

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

Стоп-стоп, анализаторы должны использовать не админы, а вы, при сборке проекта.
И вы сразу увидите, что ваш метод нечаянно перекрыл какой-то другой метод, и переименуете свой метод. Всё.
...
Рейтинг: 0 / 0
08.08.2019, 11:41
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846897
Фотография ЕвгенийВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЕвгенийВ
Участник
betelgeizexПоведение класса Base состоит в том, чтобы из метода М2 вызывать М1, при этом предполагается, что M1 может быть перекрыт в наследниках (иначе автор класса пометил бы M1 как 'final')


Т. е. хорошая практика состоит в том, что бы помечать все public/protected методы как final, если они не предполагают переопределения?

P. S. "предполагается" - это человеческий фактор, если есть малейшая возможность вляпаться, человек вляпается.
...
Рейтинг: 0 / 0
08.08.2019, 12:09
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846907
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
betelgeizexИ вы сразу увидите,конечно. Если сам прогел страный и не знает контекст, то ide обычно варнинг шлет.
...
Рейтинг: 0 / 0
08.08.2019, 12:28
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846912
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
ЕвгенийВbetelgeizexПоведение класса Base состоит в том, чтобы из метода М2 вызывать М1, при этом предполагается, что M1 может быть перекрыт в наследниках (иначе автор класса пометил бы M1 как 'final')


Т. е. хорошая практика состоит в том, что бы помечать все public/protected методы как final, если они не предполагают переопределения?

P. S. "предполагается" - это человеческий фактор, если есть малейшая возможность вляпаться, человек вляпается.на это ты не найдешь однозначного ответа.
Все ставить private чтобы не вляпаться это тоже паранойя
...
Рейтинг: 0 / 0
08.08.2019, 12:30
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846917
betelgeizex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
betelgeizex
Гость
ЕвгенийВbetelgeizexПоведение класса Base состоит в том, чтобы из метода М2 вызывать М1, при этом предполагается, что M1 может быть перекрыт в наследниках (иначе автор класса пометил бы M1 как 'final')


Т. е. хорошая практика состоит в том, что бы помечать все public/protected методы как final, если они не предполагают переопределения?

P. S. "предполагается" - это человеческий фактор, если есть малейшая возможность вляпаться, человек вляпается.

От кривых рук никакие анализаторы не защитят

Да, если метод "public final", то перекрыть (override) его не получится. Более того, не получится его и переопределить (hide) другим методом с такой же сигнатурой - в Java нет аналога 'new'. Это гарантирует, что вызывающий код всегда вызовет метод оригинального, базового класса.

Так что в каждом подходе (C# vs Java) свои плюсы и минусы.
...
Рейтинг: 0 / 0
08.08.2019, 12:35
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846940
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
betelgeizexв каждом подходе (C# vs Java) свои плюсы и минусы.+1
...
Рейтинг: 0 / 0
08.08.2019, 13:09
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846983
Фотография ЕвгенийВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЕвгенийВ
Участник
PetroNotC Sharpbetelgeizexв каждом подходе (C# vs Java) свои плюсы и минусы.+1
А как бы вы сделали, если проектировали язык с нуля?
...
Рейтинг: 0 / 0
08.08.2019, 13:58
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39846994
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
ЕвгенийВ,
Не язык а языкИ.
И они индивидуальны.
Это только MS может проектировать один всеобщий универсальный язык.
Ну, как сильверлайт типо.
Царствие ему небесное.
...
Рейтинг: 0 / 0
08.08.2019, 14:07
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847001
Фотография ЕвгенийВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЕвгенийВ
Участник
PetroNotC Sharp,
Сильверлайт - это не язык.
...
Рейтинг: 0 / 0
08.08.2019, 14:11
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847025
betelgeizex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
betelgeizex
Гость
ЕвгенийВPetroNotC Sharpпропущено...
+1
А как бы вы сделали, если проектировали язык с нуля?

А что тут проектировать? В Scala давно всё придумали до нас:

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
class A {
  def M1(): Unit = ???

  def M2(): Unit = {
    M1()
  }
}

class B extends A {
  def M1(): Unit = ??? // Error:(12, 7) `override` modifier required to override concrete member
}



Все методы виртуальные по умолчанию, но модификатор 'override' обязателен, без него ошибка.
Модификатора 'new' нет, ибо нефиг :)
...
Рейтинг: 0 / 0
08.08.2019, 14:25
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847031
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
ЕвгенийВPetroNotC Sharp,
Сильверлайт - это не язык.я про Помыслы такие, а не про язык. Сами пОмыслы греховные у тебя)
...
Рейтинг: 0 / 0
08.08.2019, 14:29
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847051
Фотография ЕвгенийВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЕвгенийВ
Участник
betelgeizex

А что тут проектировать? В Scala давно всё придумали до нас:



Все методы виртуальные по умолчанию, но модификатор 'override' обязателен, без него ошибка.
Модификатора 'new' нет, ибо нефиг :)
Тоже плохо. Вызов виртуального метода дороже, чем не виртуального. А производительность и так проседает....
...
Рейтинг: 0 / 0
08.08.2019, 14:48
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847055
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Tomin
Участник
ЕвгенийВPetroNotC Sharpпропущено...
+1
А как бы вы сделали, если проектировали язык с нуля?

Kotlin и С++ (если не забыл) обязательно требуют писать override у методов, которые перекрывают базовые.
В результате обновление библиотеки сломало бы компиляцию и потребовало бы переименовать метод.
По-моему правильный подход.
...
Рейтинг: 0 / 0
08.08.2019, 14:52
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847057
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Tomin
Участник
ЕвгенийВТоже плохо. Вызов виртуального метода дороже, чем не виртуального. А производительность и так проседает....

JVM давно уже неперекрытые методы не просто делает не-виртуальными, а даже инлайнит.
Предложено вроде в eiffel - там линковщик решал, что виртуальное, а что нет.
...
Рейтинг: 0 / 0
08.08.2019, 14:53
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847063
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
ЕвгенийВА производительность и так проседает....где?
...
Рейтинг: 0 / 0
08.08.2019, 14:58
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847065
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
ЕвгенийВТоже плохо. Вызов виртуального метода дороже, чем не виртуального. А производительность и так проседает....
Не факт

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

Оно, конечно, считать адрес из инструкции вроде теоретически проще, но не факт, что считать из таблицы виртуальных методов практически медленнее.
...
Рейтинг: 0 / 0
08.08.2019, 14:59
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847067
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
Производительность всегда относительно.
То есть где виртуальный стал узким горлышком?
Полиморфизм он вообще не для скорости. Глупо его так оценивать.
...
Рейтинг: 0 / 0
08.08.2019, 15:03
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847103
Фотография ЕвгенийВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЕвгенийВ
Участник
PetroNotC SharpПроизводительность всегда относительно.
В данном случае сравнение стоимости виртуального и не виртуального вызова.

PetroNotC SharpТо есть где виртуальный стал узким горлышком?
Смотря с чем сравнивать.

PetroNotC SharpПолиморфизм он вообще не для скорости. Глупо его так оценивать.
Речь о снижении стоимости поддержки полиморфного поведения.
...
Рейтинг: 0 / 0
08.08.2019, 16:02
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847108
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
ЕвгенийВ,
Эти слова выше просто бла бла бла ни о чем.
Удачи!
...
Рейтинг: 0 / 0
08.08.2019, 16:14
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847118
betelgeizex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
betelgeizex
Гость
ЕвгенийВbetelgeizex
А что тут проектировать? В Scala давно всё придумали до нас:



Все методы виртуальные по умолчанию, но модификатор 'override' обязателен, без него ошибка.
Модификатора 'new' нет, ибо нефиг :)
Тоже плохо. Вызов виртуального метода дороже, чем не виртуального. А производительность и так проседает....

Если для вашего приложения действительно критична скорость вызова таблицы методов, то вы просто обязаны использовать профилировщик.
Профилировщик вам покажет, какие из методов требуют оптимизации. И вы этим методам проставите модификатор final (в Scala он тоже есть), это сделает методы невиртуальными и может даже заинлайнит.

Вы придумываете искусственные проблемы, мне кажется :)
...
Рейтинг: 0 / 0
08.08.2019, 16:32
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847119
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Just-In-time Java компилятор/оптимизатор умудряется даже виртуальные метода (без всякого final) инлайнить
...
Рейтинг: 0 / 0
08.08.2019, 16:35
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847236
Фотография ЕвгенийВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЕвгенийВ
Участник
Leonid KudryavtsevJust-In-time Java компилятор/оптимизатор умудряется даже виртуальные метода (без всякого final) инлайнить
Тут бабка надвое сказала, дай ссылку на исследование? Какие нашел, там простейшие случаи.
У JIT сильно меньше возможностей, в том же времени, по сравнении например с оптимизирующим компилятором С++
...
Рейтинг: 0 / 0
08.08.2019, 21:46
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847251
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
забыл ник
Участник
ЕвгенийВLeonid KudryavtsevJust-In-time Java компилятор/оптимизатор умудряется даже виртуальные метода (без всякого final) инлайнить

У JIT сильно меньше возможностей, в том же времени, по сравнении например с оптимизирующим компилятором С++

Это с какого перепугу? Вот тут ссылку было бы как раз неплохо.
у JIT есть преимущество, потому что ему на вход поступает не только статическая(на момент компиляции) но и динамическая(как часто какой метод или цикл выполняется), так что ему все карты в руки заоптимизировать по самое небалуй. Те же полиморфик методы по дефолту JIT делает мономорфик. Если два наследника - то bimorph, а вот если уже JIT найдет третьего - тогда он деоптимизирует код и вставляет таблицу виртуальных методов
...
Рейтинг: 0 / 0
08.08.2019, 22:45
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847263
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
ЕвгенийВ,
для сферического коня в вакууме можно идти в шарп.
Все твои теоретические вопросы разбиваются о практику.
Как например неудобство совпадения имен метода - ерунда.
...
Рейтинг: 0 / 0
08.08.2019, 23:30
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847267
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
забыл ник
Участник
PetroNotC SharpКак например неудобство совпадения имен метода - ерунда.

Это далеко не ерунда. Мы в RichFaces в свое время наследовались от JSF абстрактных компонент, и добавляли свои методы. И вот пришел JSF 2 и поломал нам много чего, так что проблема не надумана. И это все следствие ублюдочного дизайна наследования и ООП в целом, когда твой код может аффектнуть изменение в чужом коде.
...
Рейтинг: 0 / 0
09.08.2019, 00:12
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847288
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
забыл никублюдочного дизайна наследования и ООПты за ФП топишь?
Мы вроде выяснили что ООП нипричем.
В дельфях есть слова в коде
f() virtual, override
...
Рейтинг: 0 / 0
09.08.2019, 08:25
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847311
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Tomin
Участник
ЕвгенийВLeonid KudryavtsevJust-In-time Java компилятор/оптимизатор умудряется даже виртуальные метода (без всякого final) инлайнить
Тут бабка надвое сказала, дай ссылку на исследование? Какие нашел, там простейшие случаи.

Это жизнь- девиртуализируются методы, которые именют не более двух ИСПОЛЬЗУЮЩИХСЯ реализаций. Например в типичном коде при вызове методов List будет учитываться только методы ArrayList
Т.е. даже если инлайна нет то вместо виртуального вызова ставится нечто вроде

if (o.type == TYPE1) staticCall TYPE1.method(o)
else if (o.type == TYPE2) staticCall TYPE2.method(o)
else убрать_всё_нафиг_и_оптимизировать_заново

ЕвгенийВУ JIT сильно меньше возможностей, в том же времени, по сравнении например с оптимизирующим компилятором С++

На разных алгоритмах разные штуки выигрывают.
И дело даже не в использовании информации о реально встречающихся типах - JIT может использовать все возможности данного процессора и информацию о времени выполнения команд именно на нём (а не на абстрактном i86x64).
И победить JIT можно либо компиляцией под конкретный процессор, а лучше ручными ассемблерными вставками. Но это стоит очень дорого.
...
Рейтинг: 0 / 0
09.08.2019, 09:31
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847408
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Leonid KudryavtsevJust-In-time Java компилятор/оптимизатор умудряется даже виртуальные метода (без всякого final) инлайнить
Я помню какой-то синтетический бенчмарк который доказывал что на виртуальных вызовах Java эффективнее С++.
Причем Java там была бородатых версий. Кажется 1.5...
...
Рейтинг: 0 / 0
09.08.2019, 12:13
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847418
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Alexey Tomin....
И победить JIT можно либо компиляцией под конкретный процессор, а лучше ручными ассемблерными вставками. Но это стоит очень дорого.
Победить JIT в общем-то элементарно. Но обычно с этим никто не заморачивается.

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

Полно ситуаций, когда легким движением руки, легко оптимизирующийся код становится не оптимизирующимся. Код работы со стримами. Насколько помню, есть два варианта вызова forEach() один вызывает унивирсальный итератор, второй заточен под типы. В результате банальная итерация по ArrayList в одном случае работает нормально (т.к. оптимизатор выключает проверку выхода за границы массива), в другом случае - жутко тормозит. Цикл по ByteBuffer в большистве случаев аналогично, можно в цикле получить жуткие тормоза, т.к. на каждом обращении идет проверка выхода за пределы массива (практическая задача перевести строки из одной кодировки в другую, для String - оптимизатор оптимизирует, для "универсальных" вызовов /ByteBuffer в Apache HTTP Components/ нифига).

Можно поискать в И-нете замеры скорости и код для быстрого преобразования String в другую кодировку.... жуть... а вроде элементарная и часто требующаяся задача
...
Рейтинг: 0 / 0
09.08.2019, 12:41
| Ответить | Цитировать | Написать  
Виртуальные методы
    #39847427
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Leonid Kudryavtsev, оптимизация кода со Streams - хорошая тема пятничного топика.
...
Рейтинг: 0 / 0
09.08.2019, 12:51
| Ответить | Цитировать | Написать  
48 сообщений из 48, показаны все 2 страниц
  все  
Форумы / Java [игнор отключен] [закрыт для гостей] / Виртуальные методы
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=59&tid=2121165]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 169ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 73ms
get tp. blocked users:
 2ms
others: 238ms
total:  530ms
созд. / загр.: 530ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]