Контексты RTTI в Delphi 2010: как это работает и как их использовать | Participants
|
- Statistics
- Participants
- Translate into Russian
- Translation result
- Translation complete.
If you do not want to register an account, you can sign in with OpenID.
Delphi 2010 RTTI Contexts: how they work, and a usage note | Контексты RTTI в Delphi 2010: как это работает и как их использовать | |
Delphi 2010 includes extended support for RTTI, also known as run-time type info or reflection. Many design approaches that have previously only been possible with managed languages like C# and Java because of the code annotation and introspection they required should now be possible in the Delphi world. | Delphi 2010 включает в себя расширенную поддержку RTTI, также известную как информация о типах времени выполнения (run-time type info) или рефлексия. Множество подходов в проектированию раньше были доступны только в управляемых языках, таких как C# и Java, так как для них необходима аннотация кода (<a href="http://en.wikipedia.org/wiki/Source_code_annotation">code annotation</a>) и интроспекция (самоанализ). Теперь это возможно и в мире Delphi. | |
Something somewhat interesting about how the RTTI works is its approach to object pools. Delphi isn't a garbage collected language, so users need to be careful to free objects when they're no longer needed, either explicitly, or by designing or using some kind of ownership scheme, such as that used by TComponent, where the Owner takes care of destruction. | Что интересно в работе RTTI, так это его подход к организации пулов объектов. Delphi - это язык, не использующий "сборку мусора", так что пользователям нужно быть внимательными и уничтожать объекты, когда они больше не нужны, делая это явно, или создавая или используя какие-нибудь схемы владения (объектами), такие как используются TComponent-ом, где владелец (Owner) берет на себя ответственность за уничтожение объектов. | |
Type information usage scenarios don't mesh particularly well with a TComponent-style of ownership. Typically, when working with RTTI, you want to do some kind of search for interesting objects, do something with them, and then go on your way. That means that many objects may get allocated for inspection, but not actually be used. Managing those objects' lifetimes independently would be tedious, so a different approach is used: there is a single global RTTI object pool. While there is at least one RTTI context active in the application, this object pool keeps all its objects alive. When the last context goes out of scope, the objects get freed up. | Порядок использования информации о типах не очень хорошо сочетается со схемой владения в стиле TComponent. Обычно, работая с RTTI, вам требуется выполнять поиск интересующих вас объектов, что-то с ними делать и продолжить работу дальше. Это означает, что множество объектов могут быть определены для проверки, но в действительности не использоваться. Управление временем существования этих объектов должно быть довольно утомительно, поэтому использован другой подход: единый глобальный RTTI пул объектов. Пока хотя бы один RTTI контекст активен в программе, пул объектов хранит все свои объекты в актуальном состоянии. Когда последний контекст выходит из области видимости - объекты освобождаются. | — tedious - утомительно — r3code |
The pool management works by using a Delphi record that contains an interface reference. The first time any given RTTI context is used, it fills in this interface reference. It can't fill it in any later than first use, because Delphi records don't support default constructors, which besides have their own problems. For example, how do you handle exceptions in default constructors, in all the places they can occur? Allocating arrays, thread-local variables, global variables, global variables in packages, temporary objects created in expressions, etc. It can get ugly, and in C++ it sometimes does. | Управление пулом для работы использует запись Delphi, которая содержит ссылку на интерфейс. Когда любой переданный RTTI контекст используется в первый раз, он помещается в эту ссылку на интерфейс. Он помещается туда только в первый раз - однократно, потому что записи Delphi не поддерживают конструкторов по умолчанию, которые к тому же имеют свои собственные проблемы. Например, как вы обрабатываете исключения в конструкторе по умолчанию, во всех точках, где они могут возникнуть? Создание массивов, локальных для потока переменных, глобальных переменных, глобальных переменных в модулях, временных объектов в выражениях, и т. д. Это может стать отвратительным, как иногда C++ это и делает. | |
So, this first use allocates an interface, called a pool token. It acts as a reference-counted handle to the global object pool. For so long as this interface is alive, the the global object pool should stay alive. Even if the RTTI context is copied around, Delphi's built-in interface handling logic, designed along COM principles, will ensure that the interface doesn't gets disposed of prematurely or get its reference count muddled up. And when an RTTI context goes out of scope, either by being a local variable in a function that is exited, or a field in an object that is freed, the reference count is reduced. When it hits zero, the pool is emptied. | Таким образом, первое использование создает интерфейс, называющийся токен пула (pool token). Он действует как некий дескриптор со счетчиком ссылок, указывающий на глобальный пул объектов. До тех пор пока этот интерфейс актуален (существует), глобальный пул объектов будет оставаться актуальным. Даже если RTTI контекст куда-то скопирован, встроенная в Delphi логика управления интерфейсами, созданная на базе принципов COM, позволяет быть уверенными, что интерфейс не будет преждевременно удален, счетчик ссылок будет иметь верное значение. И когда RTTI контекст выходет из области видимости, или будучи локальной переменной в функции, которая завершилась, или полем в удаленном объекте, счетчик ссылок уменьшит свое значение. Когда счетчик сслылок достигнет нуля - пул опустошится. |
— лучше вернуть "принципов" вместо "подходов" - звучит красивее. а должны быть - имхо вообще лишнее — TDelphiBlog
Сорри, лучше всё-таки оставить подходы. — TDelphiBlog