Изменить VMT

← →
DevilDevil © (2007-07-24 17:09) [40]

> Он попросил пример модификации VMT. Дали. А что дальше.
> Неизвестно.

Попробовать так и не успел; на днях попробую.

Ну как сказать... во-первых, просто хочется, чтобы объекты в любом случае удалялись. Во-вторых, есть такие объекты, который обязательно нужно удалить... и сделать это нужно в определённое время. Допустим вы пишите менеджер текстур; все текстуры в любом случае должны удалиться. Только сделать это они должны до удаления контекста устройства.

Как минимум, необходимость в хранении массива таких объектов есть. + Объект должен сам себя записывать в такой массив, и сам себя из него удалять.

Я хоть и не блеснул умением объяснять, надеюсь, вы хотя бы стали допускать необходимость в том механизме, который я стараюсь реализовать.

← →
Инс © (2007-07-24 17:17) [41]

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

← →
DevilDevil © (2007-07-24 17:46) [42]

я об этом уже писал.

делается это действительно просто: создаётся базовый класс, от которого в дальнейшем наследуются все мои классы.

DevilDevil © (23.07.07 17:00) [22]
Реальной какой-то пользы от такой функции я не жду ... , но:
1) интересно написать такую функцию
2) она может понадобиться

← →
DevilDevil © (2007-07-26 10:48) [43]

> oxffff © (23.07.07 15:55) [20]

Спасибо, всё работает как надо.

Если что, вот полученный модуль: http://forum.mirgames.ru/index.php?act=Attach&type=post&id=3247

Ну и если хотите пообсуждать, вот ветка:
http://forum.mirgames.ru/index.php?act=ST&f=5&t=3986&st=0#entry62664

← →
oxffff © (2007-07-26 11:21) [44]

To DevilDevil © (26.07.07 10:48) [43]

lea edx, [eax + VMTOFFSET TObject.AfterConstruction] // edx - указатель на AC
add eax, VMTOFFSET TObject.BeforeDestruction // eax - указатель на BD

mov ecx, AfterConstruction
mov [edx], ecx
mov ecx, BeforeDestruction
mov [eax], ecx

А кто будет вызывать original AC, BD обработчики?

← →
DevilDevil © (2007-07-26 11:45) [45]

да вот я думаю, может не заморачиваться на них?
всё равно, врядли их кто то использует. Ни в одной книге я о них не слышал.

← →
oxffff © (2007-07-26 12:25) [46]

Собственно не касаясь выбора способа решения.

А как же?

TCustomForm.AfterConstruction;
TDataModule.AfterConstruction;

TCustomForm.BeforeDestruction;
TDataModule.BeforeDestruction;

TComponent.BeforeDestruction;

← →
Игорь Шевченко © (2007-07-26 12:33) [47]

> да вот я думаю, может не заморачиваться на них?
> всё равно, врядли их кто то использует.

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

← →
DevilDevil © (2007-07-26 12:52) [48]

мда...

Тогда нужно хранить ещё один массив записей (класс, AC, BD) ...

> Тогда нужно хранить ещё один массив записей (класс, AC,
> BD) ...

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

эээ ?

нет, вызывать методы предка реально. Сделать это можно описанным мной выше "способом". А как это "по человечески" ?

> нет, вызывать методы предка реально.

Реально - inherited. Более далекого предка - в принципе тоже реально. Побегать по VMT. Но вот только в хорошо спроецированной системе такого быть не должно. Если это требуется - значит система спроектирована плохо.

> А как это "по человечески" ?

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

Изменить VMT Найти похожие ветки