Création d'une structure dynamique

Bonjour.

D'ordinaire, pour instancier une structure dans un programme Delphi, il suffit de déclarer la définition de la structure et d'en instancier une variable. Le tout codé en dur dans le source du programme bien sur.

Ma question est la suivante :

Je souhaite instancier une structure dont la définition (MaStruct = record [...mes proprietés...] end) n'est donnée qu'à l'execution.

Entendons-nous bien, le problème n'est pas de stocker ces valeurs en mémoire, ça je sais le faire en passant par d'autres moyens. Ce que je souhaite faire, c'est déclarer la "définition" d'une structure à l'execution (description fournie dans un xml par exemple) puis instancier cette "structure dynamique".

Le but est qu'en mémoire, les données de l'instance de cette "structure dynamique" soient exactement identique à celles qu'auraient été une instance d'une structure normale.

Toute aide sera la bienvenue.

Merci.

Jbat.;)

Hum, cela peut aller loin, disons, que si ce n'est que pour faire une image de la structure, tu peux allouer via GetMem un bloc mémoire, puis écrire toi même dans ce bloc, les données via des CopyMemory successifs (ne prend que des types finis genre integer ou shortstring, ...)

Peut-être devrait tu expliquer ce que tu veux vraiement faire ?
Si c'est pour envoyer les données vers un Stream sur TCP/IP ou vers un Fichier, et que tu dois absolument avoir un format type structure, c'est vrai que ce n'est pas évident ...

Re

Merci pour ta réactivité. 8-)

Voici ce que je souhaite faire.

J'ai un programme qui a est capable d'exploiter des DLL inconnues de lui au moment de sa compilation. Au moment de l'execution, il n'est aidé que par un fichier qui décrit les fonctions exportées ainsi que l'ordre et les types des arguments de chaque fonction. Pour transférer des valeurs simples, mon programme dépose simplement sur la pile (via des instructions assembleur) les valeurs requises en fonction de la convention d'appel spécifiée (stdcall, register, etc...).
Tant qu'il s'agit de types simples, il est possible de les empiler. Sauf qu'aujourd'hui, nous souhaitons pouvoir passer des tableaux ou des structures voir des tableaux de structures etc... Bref, des types élaborés pour nous permettre de nous interfacer avec des DLL plus complexes.

Notre hypothèse est que les types élaborés ne sont pas transmis directements sur la pile, mais leur ce serait leur pointeur qui est empilé (et en plus, nous n'en sommes même pas sur). La DLL récupèrera donc ce pointeur et sera en mesure d'utiliser la structure. Encore faut-il que nous ayons instancié correctement la structure dans notre programme afin de fournir un pointeur pointant vers une zone mémoire correctement formatté en relation avec ce que la DLL s'attends à trouver à l'adresse de ce pointeur.

C'est pourquoi si je déclare la structure dans le code source, tout fonctionne, mais je ne peux pas déclarer la définition de la structure dans le code source car sa définition doit pouvoir être donnée par un fichier externe.

Voilà pourquoi je voudrait instancier une "structure dynamique"... Je ne suis pas sur d'avoir été clair :?

Lol, le Modèle COM n'est pas justement là pour cela ? avec les Bibliothèques de Type ?

ces DLL, tu en seras l'auteur ou elles devront suivre le modèle imposé ? ou alors n'importe quel DLL devra pourvoir être utilisée ?

Pour ne pas echanger entre ton programme et ces DLL, des buffers XML (principe du SOAP) ... même si ton défit de programmation est très interessant (si je n'avais que cela à faire, ça me ferait bien plaisir de faire ce genre de dev ...) mais tu risque de partir dans quelques d'assez compliqué ...

Sinon, il faut que tu définisse un protocole de données mis à plat, comme on le ferait pour un echange de données via TCP\IP, ...

As-tu songé à de la génération de code automatique pour générer une sorte de connecteur entre la DLL et ton Exe ? ou au DelphiScript ?

Bonjour.

Je ne connais pas toutes les techniques que tu proposes en lieu et place de l'architecture actuelle et je serait joyeux de pouvoir les mettre en place - je n'aime pas trop faire de la programmation à l'ancienne - , mais le programme existait déjà avant que je ne rejoigne ce projet et il ne faut surtout pas changer ce qui "fonctionne"... :?
Qui plus est, pour répondre à ta question, il faudrait que le programme soit capable d'exploiter n'importe quelle DLL, qu'elle ai été développée en interne ou à l'externe.

D'accord,

"il ne faut surtout pas changer ce qui "fonctionne"... ", c'est le principe du TPCM (touche pas, ça marche) de Pleinpopossum ... :mouarf:

Alors, effectivement, si cela doit être compatible avec n'importe quelle DLL, tu dois passer par de l'écriture mémoire dans un bloc (GetMem, CopyMemory, FreeMem) ... en fait tu veux faire un principe de RTTI dynamique ... tu devrais lire "Enregistrement de record non finalisé", pour maitriser la gestion d'un record à la main, faut que tu maitrise déjà parfait leur fonctionnement (initialization, libération, alignement mémoire, ...), d'ailleurs, si SJRD pouvait faire un tour dans ce sujet ... il devrait pouvoir nous donner des idées (voire une lib déjà prête ... :yaisse2:)

Bon je ne sais pas si cela va convenir mais je vais quand même exposé une solution que l'on avait mis en place dans mon ancienne entreprise et que je trouvais vraiment sympa.

L'idée est d'utiliser les Variants mais surtout le fait qu'un Variant puisse être un tableau de Variant (voir la routine VarArrayCreate). L'idée est que la DLL ne prennent qu'un seul paramètre de type OleVariant qui est en fait un tableau de Variant créé dynamiquement.

Côté expéditeur on dispose d'une classe qui permet d'ajouter un élément (paire nom:String/valeur:Variant) et une méthode d'export qui va compacter les éléments dans une variable Variant stockant un tableau de Variant. La méthode d'export va donc créé un tableau du nombre d'élément puis remplir chaque case avec un autre tableau de variant contenant deux cases : une pour le nom et l'autre pour la valeur.

Côté receveur on dispose d'une classe qui décompacte le tableau en le parcourant (grâce au fonctions Low et High) et pour chaque case du premier tableau on prend le tableau qu'elle contient et on extrait d'une part le nom et d'autre part la valeur, chaque couple étant réinjectée dans une collection avec des méthodes pour obtenir une valeur suivant le nom etc...

Et inversement pour envoyer des réponses ;)

Merci Aka Guymelef pour ta proposition, mais je ne maitrise pas les DLL auxquelles je dois me connecter. Je ne peux donc pas mettre en place une solution "inventée", si ingénieuse soit-elle. Je dois reproduire exactement ce qu'il se passerai si j'appelais la dll de façon statique.

[Digression ON]

Citation:

---

Quant au TPCM => Je subit ! :( Mais je peux pas arriver dans le projet et dire "Salut, c'est moi et je vais tout révolutionner"... Surtout que dans l'industrie, ils ne connaissent pas nos normes et nos standards... Dans l'industrie, la programmation d'un logiciel n'est vue que comme une suite de If-Then-Else-goto ou à peine plus. Du moment que ça marche, pourquoi se soucier de faire les choses bien comme les règles de l'art. :ouin:

---

[Digression OFF]

J'ai donc effectivement commencé à étudier les notions d'alignements des données en mémoire pour tenter à terme de creer de toute pièces une simili structure dont je pourrais transmettre le pointeur à la DLL. Je ne sais pas si ça mènera quelque part, mais on avance ;)

Ha oui effectivement ma solution suppose que les deux bouts savent gérer ce qui est transmit ce qui n'est pas ton cas hélas.

Citation:

---

Envoyé par Aka Guymelef

... L'idée est que la DLL ne prennent qu'un seul paramètre de type OleVariant qui est en fait un tableau de Variant créé dynamiquement.

---

Dans une de mes anciennes boites, c'était aussi le principe, par un tableau de variant multi-dimensionnel ... on échangeait aussi par Variant le Data d'un TClientDataSet ... mais comme jbat l'a dit, il n'est qu'utilisateur des DLL, cela complique l'affaire, et la rend très intéressante ...

Citation:

---

Envoyé par jbat

Dans l'industrie, la programmation d'un logiciel n'est vue que comme une suite de If-Then-Else-goto ou à peine plus.

---

Cela dépend des sociétés, il est vrai que la partie hardware genre acquisition de terrain de bus est spécifiques à chaque, mais ayant fait aussi de l'industrie (pilotage de trieuse automatisée), on peut aussi faire propre, bon j'avoue, je faisais bcp de procédurale à l'époque, mais en relisant mon code, j'ai vu les objets que j'aurais pu faire ... et donc si tu fais de l'industrie, cela doit être dur :

Citation:

---

Envoyé par jbat

je n'aime pas trop faire de la programmation à l'ancienne.

---

Moi, je fais de l'informatique de gestion, on devrait tout faire objet, tout beau, mais on ne le fait pas non plus, pourtant j'adore faire de l'objet surtout le polymorphisme mais de temps en temps, allez dans les tréfonds (RTTI, ASM, mémoire ...) cela fait bien plaisir, et puis les programmeurs bas niveaux vont se rarifier, les écoles qui passe au .NET sont en train de créer une génération de développeur qui ne savent pas ce qu'est un pointeur et tous les concepts qui vont avec ... ce qui va rendre les prog indus très recherchés, un peu comme les dev COBOL, ils sont tellement rare (ou déjà en poste) que les salaires ont grimpés ... une aubaine ! non ?

Sinon, donc, je confirme, tu dois connaitre sur le bout des doigts comment sont stockés en mémoire les structures, les tableaux, les types simples, ... et tu vas devoir le faire à la mano ... hum, je confirme, j'adorerais faire ce projet ...

Citation:

---

Envoyé par ShaiLeTroll

Dans une de mes anciennes boites, c'était aussi le principe, par un tableau de variant multi-dimensionnel ... on échangeait aussi par Variant le Data d'un TClientDataSet ...

---

Exactement pareil :D

Sinon je rejoint tes propos ShaiLeTroll, moi je le vois avec .NET et ses FrameWork où tu ne fais plus attention à rien parce que le garbage collector "saura faire" et où le sens d'optimisation mémoire/rapidité semble disparaître au fur et à mesure que les langages deviennent plus évolués (paraît-il ?). Parce que c'est vrai qu'en Cobol chaque ligne, chaque variable avait son importance et devait être optimisé au maximum au vu des machines de l'époque... Maintenant on a trop tendance à se reposer sur les capacités faramineuses supposées des machines (syndrôme Vista et ses 700Mo en mémoire vive avec les graphiques au minimum ??). Mais pardon j'ai quelque peu dérivé du sujet :aie:

Rebonjour.

Je suis toujours sur mon "super" projet. :lol:

J'ai trouvé dans le "guide du language Delphi" (le "petit" bouquin fourni avec Delphi quand on l'achète) au chapitre 11 une explication détaillée de comment il organise les données en mémoire.
Le truc a beau avoir été écrit en français, parfois, c'est du chinois pour moi :?


Alors, je ne suis pas sur d'avoir tout compris... Et je suis sur de n'avoir rien compris à ce que j'ai mis en rouge :oops:

Quelqu'un pour m'aider ? ;)

Citation:

---

Envoyé par Page 11-8, description de l'organisation en mémoire des structures (record).

Pour que l'alignement des champs soit correct dans un type enregistrement décompacté, le compilateur insère un octet inutilisé avant les champs ayant un alignement de 2, et jusqu'à trois octets inutilisés avant les champs ayant un alignement de 4, si nécessaire. Enfin, le compilateur arrondit la taille totale de l'enregistrement jusqu'à la limite en octets spécifiée par l'alignement le plus grand des champs

Si deux champs partagent une spécification de type commune, ils sont compactés même si la déclaration ne comprend pas le modificateur packed et si le type enregistrement n'est pas déclaré dans l'état {$A-}. Ainsi, par exemple, soit la déclaration suivante :

Code:

---

1 2 3 4 5

Type TMyRecord = record A,B : Extended ; C : Extended ; end;

---

A et B sont compactés (alignés sur les limites en octets) car ils partagent la même spécification de type. Le compilateur complète la structure avec des octets inutilisés pour s'assurer que C apparait sur limite de mot quadruple.

Lorsqu'un type enregistrement est déclaré dans l'état {$A-} ou lorsque la déclaration comprend le modificateur packed, les champs de l'enregistrement ne sont pas alignés, mais des déplacements consécutifs leur sont plutôt affectés. La taille totale d'un tel enregistrement compacté est simplement la taille de tous les champs. Comme l'alignement des données peut changer, c'est une bonne idée de compacter toutes les structures enregistrement que vous avez l'intention d'érire sur disque ou de passer en mémoire à un autre module compilé avec une version du compilateur différente.

---

Ah, l'Alignement mémoire, ... en fait, par défaut en window l'alignement mémoire c'est 4...

Voir ce sujet Commande Sizeof "imprécise"

tient, cet autre sujet "[D5] Charger rapidement un type record Afficher un message " et sa suite ICI, ignore les délires, cela fait parti de la conversation, mais j'explique les alignements par des exemples, par contre, je ne connais pas toutes les règles ...

Salut,

Merci shai, tes liens sont très intéressants et je vois que d'autres se sont penchés sur des trucs tordus comme moi :? ...

Si je reprends l'exemple de la structure ci-dessus, j'aurais pensé à :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

type TMyRecord = record A,B : extended ; C : extended ; end; var ABC : TMyRecord ; iToto : Longint ; begin ABC.A := -1 ; ABC.B := -1 ; ABC.C := -1 ; iToto := MaxInt-1 ; ShowMessage(format('Taille occupée par ABC : %0:d',[sizeof(TMyRecord)]));

---

A : 10
bourrage : 0 (A et B sont compactés car ils partagent la même déclaration)
B : 10
bourrage : 4 (B et C ne sont pas compactés 10+10 + 4 = 24 mod 8 = 0)
C : 10
bourrage : 6 (la taille de la structure est arrondie à l'alignement requis par l'enregistrement le plus grand si j'ai bien compris - ce dont je ne suis pas sur du tout... donc 24 + 10 + 6 = 40 mod 8 = 0)
=> 40 octets.

Il y a un octet que je ne comprends pas (dernière colonne, 5ième ligne) Cet octet semble signaler la fin de la structure, mais pourquoi ? Et est-ce bien ça ?

De plus, le message affiche effectivement 40 octets, alors pourquoi iToto apparait-il si loin (16 octets plus loin) ?

Voici mon image mémoire :

Citation:

---

00 00 00 00 00 00 00 80
FF BF 00 00 00 00 00 00
00 80 FF BF 00 00 00 00
00 00 00 00 00 00 00 80
FF BF 00 00 00 00 00 01
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
FE FF FF 7F xx xx xx xx

---

SizeOf renvoie bien 40 ???
Cela me semble énorme !

Sinon, attention, les règles d'alignement sont pour les structures, pour les variables indépendants c'est encore différent ... Delphi est libre de faire ce qu'il veut, c'est sa tambouille à lui ...

une remarque, pê stupide : est-on sûr qu'une dll ne puisse attendre un autre calage que celui utilisé par delphi pour ses records ?

Remarque pertinente, par convention, sous Windows, l'alignement mémoire selon les docs est de 4 ou de 8 ... faudrait trouver laquelle c'est vraiement

suffit de voir la première directive de l'unité Windows.pas

Code:

---

{$ALIGN ON}

---

Est-ce que ALIGN ON = A+, si oui, c'est que c'est 8, bien c'est la valeur par défaut en Delphi ... je l'ai lu aussi dans l'aide SDK fourni avec Delphi, j'ai lu que c'était 8...

Normalement, c'est le même alignement qu'en C++, et encore une fois, c'est pas clair, on dirait que l'alignement 4 ou 8 est choisi en fonction de la structure ...

Nous aurions besoin de lumière à ce sujet ...

Mais si l'on se recentre :

Citation:

---

Envoyé par jbat

Ce que je souhaite faire, c'est déclarer la "définition" d'une structure à l'execution (description fournie dans un xml par exemple) puis instancier cette "structure dynamique".

---

Dans le XML, le type d'alignement sera une information à spécifier, on peut supposer que ce XML sera réalisé à la main à partir d'un fichier header ou généré via un outil genre Rational Rose ... en tout cas, le contenu de la DLL sera connu ...

Je n'avais pas pensé à déclarer la valeur des alignements parce que je les croyais constants, mais bon, à la rigueur, on peut les rajouter dans une propriété facultative des noeuds xml :)

C'est une bonne idée. Merci.:roll: