Even if packages won't work, there is a compromise solution. One can still
re-arrange the existing hierarchy. The default TObject.InheritsFrom is as
before - traverses the tree. However, a custom class may use the fact that
the arrangement is linear. This way, if one has a big custom hierarchy of
classes in a single-sourced library, then the search can be O(1) within
the library and O(Depth) outside. If the custom class is near the top of
the tree, say TPersistent, that the algorithm will be fast
Peter Popov
On Sat, 21 Jul 2007 15:14:56 -0500, Bram Kuijvenhoven
<[EMAIL PROTECTED]> wrote:
Marco van de Voort wrote:
Peter Vreman wrote:
There is no garauntee either within a single unit. With forward
defined classes you can make any
order you want.
And relying on order in memory has also problems with shared
libraries. afaik there is no rule
that new libaries are always loaded at larger adresses
Thank you for this information, Peter. I hadn't thought of shared
libraries yet.
Anyway, as far as I understood shared libraries each have their own
VMTs,
so you can't compare classes that come from different dll's or the main
executable. Is that correct?
For pure shared libraries yes, for packages no. For packages, Peter is
right.
[...]
Assume everything on the 1st and 2nd level above is in a package A.
Progam B and C both use package A. What do we do about lastinsubtree?
Before I could answer that question, I needed to know a little bit more
about packages and of how VMTs are handled in packages. ... Found
http://wiki.freepascal.org/packages. So I assume we are talking about
'library packages' here.
If a package is loaded dynamically, the preorder indices in the VMTs
would need to be recalculated. If it is loaded statically, the compiler
can do the calculation on beforehand. Of course the loading of packages
must be done synchronized (in a critical section), but that might
already have been the case. Also, it should be made possible to
enumerate the VMTs that do reside in a package.
I think this outweighs the performance gain for InheritsFrom (and 'is'
and 'as'), and it is most beneficial for applications that do not use
packages.
BTW does the compiler optimize
if (obj is TMyObject) then
SomeCodeWith(obj as TMyObject)
to
if (obj is TMyObject)
SomeCodeWith(TMyObject(obj))
(under the condition that SomeCodeWith does not change obj.)
Regards,
Bram
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
