Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Определение адреса метода изнутри

Страницы: < 1 2
Alex_Ne © (2007-11-12 15:26:00)
Добрый день! Каждый метод имеет ссылку на собственный обект (переменная Self). А что делать, если код метода должен получить адрес или имя самого метода? Можно ли его извлечь
откуда-либо.
Вбивать для каждого метода код типа

procedureDestСomp.AnyoneMethod(Sender: TObject);
varCode : pointer;
begin
Code := MethodAddress('AnyoneMethod');
или
Code := @AnyoneMethod;
............................................
end;

как-то представляется не очень красивым и правильным. Хотелось бы иметь универсальный подход. Т.е. последовательность операторов, не требующую изменений и позволяющую внутри метода получить его адрес или имя.
Но облазив Help не нашел ничего подходящего. Может кто сталкивался с подобной проблемой?
Заранее спасибо.

Alex_Ne (2007-11-12 18:27:00) [21]

> Почитай мой блог.
> http://santonov.blogspot.com/
> Может, что пригодиться.

Спасибо за ссылку. Тем более что я не силен в ассемблере,
а разбираться все равно нужно - назрела необходимость.

oxffff (2007-11-12 18:00:00) [22]

> Может, что пригодиться.

Мне реально нужно другие книги читать. Начать с букваря.

пригодится

oxffff (2007-11-12 17:42:00) [23]

> Alex_Ne (12.11.07 15:46) [2]

Почитай мой блог.

http://santonov.blogspot.com/

Может, что пригодиться.

oxffff (2007-11-12 17:36:00) [24]

> Сергей М. © (12.11.07 17:25) [11]

>Никто не понуждает держать адрес возврата в стеке.

Ого. А тогда ret узнает об этом. Если работает со стеком.
Извольте прочитать работу RET. :)

Вы всегда в своем звездном репертуаре.
За сим откланиваюсь.

Alex_Ne (2007-11-12 17:33:00) [25]

> Все это делается средствами IDispath-интерфейсов и их наследников.
>
> И при этом нет никакой нужды держать библ-ку типов на стороне
> контроллера.

Разумеется. Вот я и делаю максимально простой IDispath-интерфейс про который затем можно забыть и сосредоточиться на функциональных компонентах.
Не претендую на универсальность, но для моего проекта такой подход до сих пор был более эфективен чем стандартные диспинтерфейсы.

Сергей М. (2007-11-12 17:26:00) [26]

> Borland не предусмотрели штатных механизмов доступа к эт
> им адресам

Зато Борланд предоставил вполне приличный отладчик, умение пользоваться которым практически сводит на нет небходимость в подобного рода выкрутасах.

Сергей М. (2007-11-12 17:25:00) [27]

> я не говорю, что это невозможно

Конечно невозможно)
Никто не понуждает держать адрес возврата в стеке.

> оставьте галочку, stack frame и будет вам счастье

Мне оно нафих не нужно.
К тому же это частный случай)

Alex_Ne (2007-11-12 17:23:00) [28]
> oxffff

Это работает!!!
Огромное спасибо oxffff,
Когда смотрел исходники в System возникало подозрение, что без ассемблера не обойтись - чтож, теперь будем разбираться.
Все-таки странно, что Borland не предусмотрели штатных механизмов доступа к эт им адресам.

oxffff (2007-11-12 17:20:00) [29]

> Сергей М. © (12.11.07 17:12) [8]

Во всяком случае я не говорю, что это невозможно.

А вы эту поставьте галочку, stack frame и будет вам счастье.

Сергей М. (2007-11-12 17:12:00) [30]

> Если нет стекового фрейма, то и это можно решить

Вот и попробуй)
Причем на все случаи жизни)

oxffff (2007-11-12 17:08:00) [31]

> oxffff © (12.11.07 17:07) [6]

Если нет стекового фрейма, то и это можно решить.

oxffff (2007-11-12 17:07:00) [32]

> Сергей М. © (12.11.07 15:32) [1]
>
> > Хотелось бы иметь универсальный подход
>
>
> Нет такого и быть не может.
> Да и за каким лешим это может понадобиться - тоже ба-а-альшой
> вопрос

На здоровье.

procedure TForm1.abc;
var a,b:integer;
methodAdress:pointer;
begin
asm
mov eax,[ebp+4];
mov ecx,[eax-4];
add eax,ecx;
mov methodAdress,eax;
end;
end;

Сергей М. (2007-11-12 16:58:00) [33]

> С целью передачи клиенту по сетке

Все это делается средствами IDispath-интерфейсов и их наследников.
И при этом нет никакой нужды держать библ-ку типов на стороне контроллера.

Alex_Ne (2007-11-12 16:52:00) [34]
С целью передачи клиенту по сетке. Стандартная технология, напр. DCOM (да и другие) предполагает создание интерфейса на сервере, библиотеки типов на клиенте, и все это хозяйство еще требуется связать с функциональными объектами обоих приложений.
Двойная работа, особенно если интерфейс находится в стадии развития - все время что-то добавляется, нужно каждый раз перекомпилить и сервер и всех клиентов.

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

Для этого и потребовалось решать означенную задачу.

Сергей М. (2007-11-12 15:50:00) [35]

> нужно фиксировать каким-то образом вызовы определенных в
> базовом классе и переопределяемых (override) в потомках
> методов

Что значит "фиксировать" ? Протоколировать что ли ?
И зачем ? В целях отладки или ?

Alex_Ne (2007-11-12 15:46:00) [36]

> Да и за каким лешим это может понадобиться - тоже ба-а-альшой
> вопрос

Может. Cоздается базовый класс который умеет сериализовать свои опубликованнык свойства - это делается автоматически и распространяется на всех потомков. Следующий шаг - нужно фиксировать каким-то образом вызовы определенных в базовом классе и переопределяемых (override) в потомках методов. Вот и возникает потребность получать слепок метода, содержащий имя и значения параметров.

Сергей М. (2007-11-12 15:32:00) [37]

> Хотелось бы иметь универсальный подход

Нет такого и быть не может.
Да и за каким лешим это может понадобиться - тоже ба-а-альшой вопрос

Страницы: < 1 2

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »