Si vous perquisez assez dans Delphi Internals, vous trouverez quelque chose d'étrange et apparemment non documenté sur les enregistrements Ttypeinfo générés par le compilateur. Si le PTYPEINFO pointe vers un enregistrement Ttypeinfo à l'adresse x, au Passez tout PTYPEINFO légitime généré par le compilateur dans cette routine et elle produira la même adresse deux fois. J'ai goûté un peu à Typinfo.pas un peu, mais je ne vois rien qui mentionne ce "pointeur d'identité" ou ce qu'il est là pour. Est-ce que quelqu'un sait pourquoi c'est là? Cela semble être vrai dans chaque version de Delphi d'au moins D3 à D2010. x - 4 , vous trouverez les 4 octets suivants décrivant un pointeur sur X. Par exemple:
3 Réponses :
Peut-être que c'est une liste liée qui se trouve dans la mémoire contiguë :)
Non, car il n'y a rien à ressembler à un "prochain pointeur" dans les structures Ttypeinfo / TttyPedata. Idée intéressante, cependant.
Ne comprenez pas complètement ce qui se passe, mais lorsque vous avez un coup d'œil sur exemple Lorsque vous regardez la méthode de ClassInfo, il renvoie un pointeur simple la valeur qui semble lié à la table VMT: La valeur VMTInitTable est utilisée par exemple de sorte que les quatre octets avant la structure de typeInfo pointant vers la structure TypeInfo semblent être présentes par design et une partie de la structure VMT. EDIT < / Strong> Comme Mason a fait remarquer à juste titre que ce qui précède est un hareng rouge complet (voir commentaires). Je laisse la réponse afin que d'autres n'auront pas à la chasser. et l'appelez avec les informations suivantes: Les trois premiers produisent les résultats que Mason décrit. Je n'ai ajouté qu'un writeln supplémentaire pour montrer la valeur du pointeur pour le dernier Writeln. Le dernier appel de TryRTtistuff est de montrer que lorsque vous ne passez pas dans un pointeur à une structure de typeIfo valide, vous n'obtenez pas la même valeur sur les premier et troisième Writeln's pour l'appel. Aucun indice quant à ce qui se passe avec le typeinfo. Peut-être devrions-nous demander à Barry Kelly comme il est l'auteur de la nouvelle D2010 RTTI, alors devrait savoir beaucoup sur l'ancien aussi ... ispublisheprop dans l'unité typinfo , vous verrez qu'il jette le ClassInfo de l'instance en tant que pointeur sur une structure TypeInfo: vmtttypeinfo a une valeur de -72. Quatre octets avant que AT -76 soit vmtinittable . VMTTypeInfo est suivi de la carte de terrain, la méthodytetable, dynamictable, etc. tobject.cleanupinstance et transmis à _finalizerecord comme le pointeur à la structure typeinfo.
Désolé, mais vous regardez la mauvaise chose. TypeInfo n'est pas liée à VMTS, car il peut également exister pour des types de non-objets. Le VMT contient un pointeur à l'enregistrement TtypeInfo de la classe, mais ce n'est pas ce que je demande.
@ Mason: Vous avez peut-être parfaitement raison, mais je pensais que «l'ancien style RTTI» ne prend en charge que TypeInfo sur des classes et des énumérations? Et ce dernier que si vous n'édorciez pas de valeurs spécifiques dans la déclaration de dénombrement. RTTI pour d'autres types ne s'est pas présenté avant D2010, je pense (j'utilise D2009).
Non. Les informations de type devaient être disponibles pour tout type de base pouvant être utilisé dans une DFM, car c'est ce que le système a été inventé pour: la sérialisation et la désérialisation du formulaire.
Oh ok, bien sûr. Je pensais que les Ttypekinds étaient "juste" les descripteurs des propriétés d'une classe ", mais les types de base ont en effet leur propre structure typeinfo (je joue avec votre code comme je vais). Pitié La méthode TypeInfo est le compilateur magique, n'est-ce pas ...
Ouais, Barry's a été connu pour se présenter ici et répondez parfois aux questions. Je pense un peu qu'il ou Allen Bauer pourrait être les seuls à pouvoir donner une réponse valide à cette question. :(
C'est très simple: les packages et la liaison dynamique.
bpls sont des dlls. Les DLL sont reliées via des tables patchées, plutôt que tout le code de l'EXE ou de la liaison de la DLL par rapport à la DLL étant patchée (qui ferait beaucoup de mal à partager la mémoire en lecture seule entre plusieurs processus). Pour empêcher la nécessité d'une référence à Il est facile de voir la différence lors de la liaison statiquement par rapport à une liaison contre un BPL dans ce programme: p> sur ma machine locale, compilé avec TypeInfo (Automype) Code> quelque part dans le code, ou TypeInfo d'un EXE ou d'une DLL, étant modifiée lors de la liaison avec la BPL, il y a une indirection dans la table d'importation. DCC32 test.pas code>, il sortira: p> TObject
x 004051F0
x^ 40001DA4
J'allais juste formuler une idée assez similaire. Merci pour la perspicacité.
Donc, ce pointeur doit être quelque part pour le lien pour le faire son travail, et il arrive simplement d'être placé immédiatement avant que les données ne pointaient, lorsque ces données se trouvent dans le même module, par convention? Ok, ça a du sens. Merci.
@ Mason Tous TypeInfo Fixups - Les pointeurs d'un blob de typeInfo à une autre - sont de type PPTyEmefo, pas PtypeInfo, pour gérer le boîtier de liaison dynamique. Dans le cas de la liaison statique, il doit exister un pointeur intermédiaire pour la convention de travailler et une partie du typeInfo elle-même a le plus de sens que tout. C'est-à-dire que ce n'est pas là pour la liaison; C'est là à cause de la Convention et la Convention est là en raison de la liaison dynamique, ce qui est fait comme il est de maximiser le potentiel de partage de page.
Ah, donc c'est ce que PPTytinfo est là pour. Merci pour l'explication.
Je suppose qu'un
var est manquant dans le code ci-dessus ...@Andreas: Où? Je ne vois aucun Vars disparu ...