что будет?

← →
Vlad Oshin © (2008-04-21 12:24) [0]

TO1 = class
F:integer;
procedure Metod; virtual; abstract;
end;

TO2 = class(TO1)
procedure Metod; override;
end;

var
Form1: TForm1;

implementation

{$R *.dfm}
procedure TO2.Metod;
begin
inherited;
F:=1;
inherited;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
OO:TO2;
begin
OO:=TO2.Create;
OO.Metod;
FreeAndNil(OO);

В принципе, ничего, проверил. Почему?

← →
Palladin © (2008-04-21 12:25) [1]

Compiler Magic

← →
oxffff © (2008-04-21 12:33) [2]

Vlad Oshin © (21.04.08 12:24)

Поправь на inherited Metod;

← →
Дмитрий С (2008-04-21 12:37) [3]

ничего не будет =)
Компилятор по идее должен сообразить, что
inherited; F:=1; inherited;
ничего не делает и не включить это в exe :)

← →
oxffff © (2008-04-21 12:39) [4]

> Дмитрий С (21.04.08 12:37) [3]

Да ну?

А как компилятор по твоему сообразит, что F:=1 не нужно?

← →
Kolan © (2008-04-21 12:40) [5]

> В принципе, ничего, проверил. Почему?

Я что-то не понял, а что ожидалось?

← →
Дмитрий С (2008-04-21 12:42) [6]

> Да ну?
>
> А как компилятор по твоему сообразит, что F:=1 не нужно?
>

И в правду :) не обратил внимания на то что она у тебя не в привате

← →
Rouse_ © (2008-04-21 12:42) [7]

> В принципе, ничего, проверил. Почему?

Потому-что у тебя не шестая дельфя... :)

← →
oxffff © (2008-04-21 12:44) [8]

> Дмитрий С (21.04.08 12:42) [6]
>
> > Да ну?
> >
> > А как компилятор по твоему сообразит, что F:=1 не нужно?
>
> >
>
> И в правду :) не обратил внимания на то что она у тебя не
> в привате

Не у меня. :)

← →
Palladin © (2008-04-21 12:44) [9]

> Дмитрий С (21.04.08 12:37) [3]

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

← →
oxffff © (2008-04-21 12:47) [10]

> охффф,

65535 - охфффф

← →
Дмитрий С (2008-04-21 12:50) [11]

АбстрактЭррор=)

← →
Palladin © (2008-04-21 12:52) [12]

> oxffff © (21.04.08 12:47) [10]

извиняюсь )

← →
Vlad Oshin © (2008-04-21 13:13) [13]

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

> Palladin © (21.04.08 12:44) [9]

спасибо

← →
Vlad Oshin © (2008-04-21 13:13) [14]

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

> Palladin © (21.04.08 12:44) [9]

спасибо

← →
Vlad Oshin © (2008-04-21 13:13) [15]

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

> Palladin © (21.04.08 12:44) [9]

спасибо

← →
guav © (2008-04-21 13:19) [16]

Насколько я помню, в невиртуальном методе, которого нет в базовом классе тоже ножно написать inherited; и ничего за это не будет.
Используется в сгенерированных обработчиках событий инстанциированного фрейма, чтобы не знать назначен ли обработчик в самом прототипе фрейма или нет (т.е. если назначен, будут вызваны оба).

← →
guav © (2008-04-21 13:24) [17]

> инстанциированного фрейма

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

← →
oxffff © (2008-04-21 14:15) [18]

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

Что за муть?

← →
Anatoly Podgoretsky © (2008-04-21 14:30) [19]

> Дмитрий С (21.04.2008 12:42:06) [6]

А это что изменило, раз в привате, то на него можно плевать?

← →
guav © (2008-04-21 14:41) [20]

> [18] oxffff © (21.04.08 14:15)

Согласен, не так, я в [17] исправил. Речь идёт не о сгенерированных обработчиках событий фрейма, кода он лежит на форме, а о обработчиках при визуальном наследовании:
type
TFrame1 = class(TFrame)

другой файл
type
TFrame11 = class(TFrame1)

в обработчике TFrame11 будет inherited и при этом не важно в TFrame1 этот обработчик есть или нет.

← →
oxffff © (2008-04-21 14:44) [21]

> Anatoly Podgoretsky © (21.04.08 14:30) [19]

Чисто теоретически. Можно.
Если, нет "честного" обращения к private полю (простого типа) в модуле, то можно игнорировать любые присваивания к данному полю объекта.
Поскольку подкласс и другой модуль это другой scope. IMHO.

Однако если такое случается,то вопросы лучше задать архитектору классов.

← →
Palladin © (2008-04-21 14:45) [22]

фреймы то тут причем... и обработчики чего?

← →
oxffff © (2008-04-21 14:48) [23]

> guav © (21.04.08 14:41) [20]

Это из другой области.
Где там хотя бы виртуальный метод?

Я к тому что в обычном невиртуальном методе, отсутствующем в базовом классе можно просто написать inherited; и ничего не будет. И среда этим пользуется при генерировании кода обработчиков в фреймах.

← →
Дмитрий С (2008-04-21 15:07) [26]

> А это что изменило, раз в привате, то на него можно плевать?

Да. Он же в объекте нигде не используется.

> Дмитрий С (21.04.08 15:07) [26]

в объекте нет, в модуле - вполне может быть.

← →
Дмитрий С (2008-04-21 15:30) [28]

> вполне может быть

При компилировании delphi точно знает используется или нет, ведь так? А если не используется - значит можно оптимизировать

> Дмитрий С (21.04.08 15:30) [28]

апп на тебя наехал, а не на компилятор :)
ты откуда знаешь, используется F в private в модуле или нет? модуль не весь перед тобой.

← →
Дмитрий С (2008-04-21 15:38) [30]

> модуль не весь перед тобой.

как это не всегда??? Если F находится в привате класса. и нигде в модуле не используется, то компилятор может им пренебречь: как при компилировании exe, так и dcu. Ведь так?
Я не думаю, что компилятор расчитывает на то что к классу будут обращаться "злыми" методами:) как думаешь?

> Дмитрий С (21.04.08 15:38) [30]

модуль не весь перед тобой. откуда ты знаешь, что находится после
FreeAndNil(OO);
а в Delphi, в рамках одного и того же модуля, обращение к private полям классов разрешено, этакое подобие friend из c++

← →
Дмитрий С (2008-04-21 15:53) [33]

> модуль не весь перед тобой.

ну это уже другой вопрос:)

что будет? Найти похожие ветки