Статический вызов виртуального метода.

← →
oxffff © (2007-07-31 15:55) [0]

Предположем ситуацию, что метод должен вызвать реализацию метода перекрытого в одном из своих потомков, но именно свою реализацию.

Востребована ли будет конструкция невиртульного вызова виртульного метода?

То есть ввод ключевого слова "Типа вызова" метода.

Например

static MyvirtualMethod().

← →
Сергей М. © (2007-07-31 15:58) [1]

> oxffff © (31.07.07 15:55)

Не буду оригинален, но

"Жениться бы Вам, барин !" (с)

← →
oxffff © (2007-07-31 16:00) [2]

> Сергей М. © (31.07.07 15:58) [1]
>
> > oxffff © (31.07.07 15:55)
>
>
> Не буду оригинален, но
>
> "Жениться бы Вам, барин !" (с)

Так я женат.

Вы скажите свое мнение. Прошу вас.

← →
Сергей М. © (2007-07-31 16:03) [3]

> Вы скажите свое мнение

Так я ыть и сказал его - жениться б Вам).. На конкретном Заказчике конкретного программного продукта) ..

← →
oxffff © (2007-07-31 16:06) [4]

> Сергей М. © (31.07.07 16:03) [3]
>
> > Вы скажите свое мнение
>
>
> Так я ыть и сказал его - жениться б Вам).. На конкретном
> Заказчике конкретного программного продукта) ..

Вы пожалуйста не увиливайте.

А скажите как заставить компилятор сделать невиртуальный
вызов виртульного метода, за исключением inherited естественно.

← →
StriderMan © (2007-07-31 16:08) [5]

> Предположем ситуацию, что метод должен вызвать реализацию
> метода перекрытого в одном из своих потомков

сделай приватную невиртуальную копию метода. дергай ее если надо.

← →
Сергей М. © (2007-07-31 16:10) [6]

> А скажите как заставить компилятор сделать невиртуальный

А конкретному Заказчику не похрену ли твои героические потуги на поприще твоего противостояния с конкретным компилятором, а ?)

← →
oxffff © (2007-07-31 16:14) [7]

> StriderMan © (31.07.07 16:08) [5]
>
> > Предположем ситуацию, что метод должен вызвать реализацию
>
> > метода перекрытого в одном из своих потомков
>
> сделай приватную невиртуальную копию метода. дергай ее если
> надо.

Это одно из решений.

Еще решение есть взятие адреса метода реализации. И вызов его.

Но.

Я спросил потому, что в предложенном вами случае будет два вызова в случае виртуального метода, либо дублирование кода.

Все это затраты, либо на размер кодового сегмента. Либо на скорость вызова в случае недублирования (виртуальная функция вызывает приватный метод).

Почему мы не расширить языковые конструкции для этих целей.
Кому надо может использовать.

Я именно с это позиции и спрашиваю.

Кто за, а кто против.

← →
oxffff © (2007-07-31 16:20) [8]

> Сергей М. © (31.07.07 16:10) [6]
>
> > А скажите как заставить компилятор сделать невиртуальный
>
>
> А конкретному Заказчику не похрену ли твои героические потуги
> на поприще твоего противостояния с конкретным компилятором,
> а ?)

Я все же думаю это интересней, чем вести диалог с товарищем, который играет в прятки с процессами.
Хотя возможно из той же серии. Каждый по своему сходит с ума.

Ну что сделать. Если мне это интересно.

← →
Сергей М. © (2007-07-31 16:25) [9]

> Если мне это интересно.

Извини, но мне оно НЕинтересно, особливо после того как ты облажался по полной прогармме с выкрутасами с ESP.

← →
oxffff © (2007-07-31 16:34) [10]

> Сергей М. © (31.07.07 16:25) [9]
>
> > Если мне это интересно.
>
>
> Извини, но мне оно НЕинтересно, особливо после того как
> ты облажался по полной прогармме с выкрутасами с ESP.

Вы так сразу обижаетесь.
Ну и что.
Ну не знал я про необходимость выравнивание на DWORD стека для вызова win32. Теперь знаю. Зато нашел баг.

Я же признал это.

Кстати несколько месяцев назад была тема, в которой вы ошиблись. А я указал на это. Кстати тема была тоже связана с ASM. Вы далее по теме тихо промолчали.

После этого мне тоже кричать на каждом углу?

Опускаться до этого я не стану.

← →
Сергей М. © (2007-07-31 16:54) [11]

> oxffff © (31.07.07 16:34) [10]

Так мы с тобой быстрой разработкой чего занимаемся ?)

← →
Юрий Зотов © (2007-08-01 05:53) [12]

> oxffff
try 1. Запоминаем класс (4 байта по адресу Self). try 2. Пишем туда любой другой класс. 3. Вызываем виртуальный метод (будет вызван метод подмененного класса). 4. За последствия отвечаем сами. finally 5. Возвращаем запомненный класс обратно. end except 6. Больше так не делаем. :о) end

← →
oxffff © (2007-08-01 08:38) [13]

← →
oxffff © (2007-08-01 08:43) [14]

> Юрий Зотов © (01.08.07 05:53) [12]
> > oxffff
>
> try
> 1. Запоминаем класс (4 байта по адресу Self).
> try
> 2. Пишем туда любой другой класс.
> 3. Вызываем виртуальный метод (будет вызван метод подмененного
> класса).
> 4. За последствия отвечаем сами.
> finally
> 5. Возвращаем запомненный класс обратно.
> end
> except
> 6. Больше так не делаем. :о)
> end

Кстати предложенный вами способ может быть некорректен, поскольку
в случае, если адресуемый метод вызывает другие реализации виртуальных методов перекрытых в дочерних, то вместо этого он получит реализацию в замененной VMT.

>oxffff © (01.08.07 08:38) [13]
>Почему мы не расширить языковые конструкции для этих целей

Почему бы не расширить языковые конструкции для этих целей

← →
SlymRO © (2007-08-01 09:26) [15]

например для обхода Destroy? чтоб мемликов плодить?
хоть одно прикладное применение выдай...

← →
oxffff © (2007-08-01 09:33) [16]

> SlymRO © (01.08.07 09:26) [15]
> например для обхода Destroy? чтоб мемликов плодить?
> хоть одно прикладное применение выдай...

Может тебе перечитать еще раз. Читать [7].
Про применение читать "назначение Inline".

Далее по деструктору, с чего ты взял что мемлики будут плодиться.
Вызывай free и будет тебе счастье.

← →
SlymRO © (2007-08-01 09:48) [17]

Free вызывает подмененый Destroy...
Прикладное применение: Эта операция может потребоваться когда плохо спроектировано генеалогическое дерево класса и его структура, и без полной переделки дерева и без дублирования кода предков добиться необходимого результата невозможно...
Спрашивается: Зачем чинить последствия, когда нужно лечить причину...

← →
oxffff © (2007-08-01 10:16) [18]

> SlymRO © (01.08.07 09:48) [17]
> Free вызывает подмененый Destroy...
> Прикладное применение: Эта операция может потребоваться
> когда плохо спроектировано генеалогическое дерево класса
> и его структура, и без полной переделки дерева и без дублирования
> кода предков добиться необходимого результата невозможно.
> ..
> Спрашивается: Зачем чинить последствия, когда нужно лечить
> причину...

Ты все же хочешь настоятельно читать [7]

Вот одна из реализаций нужного мне поведения

MyClass=class
protected
procedure This_class_Behaviour;
public
procedure Polymorth_Behaviour;virtual;
procedure This_Class_Some_Method_That_Needs_This_Class_Behaviour;
end;

procedure MyClass.This_class_Behaviour;
begin
//Behaviour implementation
end;

procedure MyClass.Polymorth_Behaviour;
begin
This_class_Behaviour
end;

procedure MyClass.This_Class_Some_Method_That_Needs_This_Class_Behaviour;
begin
....
This_class_Behaviour;
....
end;

Если ты внимательно посмотришь.
То до того чтобы добраться до нужной мне реалиазации будет 2 вызова.
Если сделать inline This_class_Behaviour. То будет две идентичных реализации.
В первом случае time consuming.
Во втором code size consuming.

Есть другие реалиазции, которые тоже озвучены в этой ветке.
В них тоже идут подготовки, что приводит к time consuming.

Нужно средство аналогичное inherited, только для статического вызова конкретной реализации(в конкретном классе),

Ты подумай зачем придумали inline. Открой CompuWare Driver Studio и увидишь, как много там inline. Подумай для чего?

Ответ для того, чтобы нетратиться на время вызова и возврата.

← →
oxffff © (2007-08-01 10:18) [19]

> нетратиться

не тратиться

← →
SlymRO2 (2007-08-01 10:37) [20]

Удалено модератором
Примечание: Нарушение режима РО

← →
имя (2007-08-01 10:43) [21]

Удалено модератором

> SlymRO2 (01.08.07 10:37) [20]
> Не могу понять, ты драйвер пишешь? или у Callофобия :)
> зачем юзать высокоуровневый, процедурный язык чтоб на асме
> писать "обходы" всех его прелестей?

Радует, что ты понял меня.

Есть у меня часть разработок time critical на Delphi.
Тут конечно на ум сразу приходит отказ от ООП.
Но не хочеться жертвовать гибкостью.
Поэтому на каких то этапах можно использовать static link virtual method (not via VMT). Но было бы неплохо иметь удобное средство(решение).
Тем более, что это было бы маленький (редко используемый) language sugar.
Поскольку вводят же новые понятия.
Например Final, strict.
Что собственно противоречит ООП, но действительно востребовано, хоть и редко.

> Что собственно противоречит ООП, но действительно востребовано,
> хоть и редко.

Но концепция ООП со временем преобразуется согласно новым требованиям (реалиям времени). И как любит говорить очень хорошая знакомая каратистка: "Это хорошо".

> Но концепция ООП со временем преобразуется согласно новым
> требованиям (реалиям времени).

Это-то что-то новое.

Я полагал, что ВЦСПС до ООП еще не дотянулся, однако ж.

> Игорь Шевченко © (01.08.07 11:08) [24]
>
> > Но концепция ООП со временем преобразуется согласно новым
>
> > требованиям (реалиям времени).
>
>
> Это-то что-то новое.
>
> Я полагал, что ВЦСПС до ООП еще не дотянулся, однако ж.

Буч уже в срочном порядке переписывает книги. :(

Вы правы. Я некорректно выразился.

> strict.
> Что собственно противоречит ООП

strict противоречит ООП, вы что. Да это наоборот без strict ООП в Delphi противоречило всему чему токлько можно.
кроме того без strict лично я делал кучу ошибок.

Например:
TClassA = class private FA: Integer; public property A: Integer read FA write FA; end; TClassB = class private FObjectA: TClassA; public procedure Foo; end; proceudre TClassB.Foo; begin FObjectA.FA end;

И млин все работает. А потом если из модуля скопировать только TClassB начинается&#133
:(

> strict противоречит ООП, вы что. Да это наоборот без strict
> ООП в Delphi противоречило всему чему токлько можно.
> кроме того без strict лично я делал кучу ошибок.

А как же Friends?

Статический вызов виртуального метода. Найти похожие ветки