Déclaration dynamique de variable

Bonjour à tous,
est-ce que quelqu'un saurait comment faire pour ne pas déclarer les variables en dur dans le code?
J'aimerais lire le nom des variables avec leur type dans un fichier et les déclarer.
Mais le problème c'est que je ne sais pas comment transformer une chaine de caractères en un nom de variable.

Merci d'avance

S'il s'agit de le faire à l'exécution du programme, ce n'est pas possible. D'ailleurs, comment utiliserais-tu ensuite ces variables? Une solution est d'utiliser un conteneur (un tableau, une liste, ...) d'éléments contenant une chaîne de caractère pour leur nom et un bloc mémoire associé.

Mais quel est l'objectif exactement?

Ce que je cherche à faire c'est créer une dll permettant de faire quelques traitements. Elle doit être générique et compatible avec plusieurs IHM et contenant des variables différentes. Ces variables seront définies dans un fichier texte, et certaines d'entre elles seront initialisées dans un fichier .ini

Quels est le rôle de ces variables ? Sont-ce les données à échanger entre ta bibliothèque et l'application qui l'utilise ? Je pense que c'est un problème de conception de l'interface de ta bibliothèque.

oui, une partie de ces variables est commune entre l'IHM et la dll, elles correspondent à ce qui est entré dans l'IHM, et les autres sont des valeurs min et max (initialisées dans le .ini) de certaines ces variables. Le but est de faire un bornage et de renvoyer le résultat vers une autre appli.

En préambule: tel quel, la DLL ne permet pas l'échange de données entre deux applis.

Ensuite, j'ai l'impression que tu as fait un amalgame entre nom de variable et échange de données entre deux modules. Normalement, l'interface de ta DLL doit permettre de passer de telles données :
[DLL] Interface.h

Code:

---

1 2	int min(int i1_, int i2_);

---

[DLL] Interface.c

Code:

---

1 2 3 4 5

int min(int i1_, int i2_) { return (i1_<i2_)?i1_:i2_; }

---

[Application] Dialog.c (exemple):

Code:

---

1 2 3 4 5 6 7 8

void OnCheckBoxClick() { int edit_1 = GetValeurEdit(IDC_EDIT_1); int edit_2 = GetValeurEdit(IDC_EDIT_2); int resultat = min(edit_1, edit_2); /* ... */ }

---

D'accord, je ne m'y prenais pas de la bonne manière. C'est la première fois que je fais une dll, j'avais une mauvaise vision des choses depuis le départ. Je vais essayer de m'y prendre autrement.

Merci beaucoup

pour te préciser la situation :

DLL = Dynamic Linked Library

(c'est à dire bibliothèque liée dynamiquement)

par opposition à

SL = Static Library

(c'est à dire bibliothèque liée statiquement).

Dans le cas de la DLL, quand tu fais l'édition de lien (link) d'un programme faisant appel à une fonction de la DLL, le linker (l'éditeur de lien) inclus dans le binaire un saut à l'adresse de la bonne fonction.

Dans le cas de la SL, il inclus le code de la bonne fonction.

Avantages et inconvénients :

• Avantage : Un binaire utilisant une DLL est donc plus petit (contient des adresses et non du code).
• Inconvénient : Un binaire utilisant une DLL est en général plus lent que le même binaire utilisant une SL, car le système doit charger en mémoire la DLL lors d'un appel, et de plus il doit communiquer les variables lors des appels.

Citation:

---

Envoyé par souviron34

Inconvénient : Un binaire utilisant une DLL est en général plus lent que le même binaire utilisant une SL, car le système doit charger en mémoire la DLL lors d'un appel, et de plus il doit communiquer les variables lors des appels.

---

Je rajouterai ou compléterai en disant : plus lent au chargement, oui, je suis d'accord, à l'exécution, non je ne suis pas d'accord. Il y a peut être une table d'indirection supplémentaire mais c'est non significatif la plupart du temps.

Quant au fait de communiquer les variables lors des appels, c'est le même problème et donc la même charge en édition de lien statique ou dynamique.

Citation:

---

Envoyé par ram-0000

Je rajouterai ou compléterai en disant : plus lent au chargement, oui, je suis d'accord, à l'exécution, non je ne suis pas d'accord. Il y a peut être une table d'indirection supplémentaire mais c'est non significatif la plupart du temps.

Quant au fait de communiquer les variables lors des appels, c'est le même problème et donc la même charge en édition de lien statique ou dynamique.

---

Je dirais que ça dépend.. ;)

Le point 1 : ça dépend si le binaire est très gros (swap), ainsi que si les appels à la biblothèque sont fréquents ou non (elle peut se décharger).

Le point 2 : oui.

Citation:

---

Envoyé par souviron34

Je dirais que ça dépend.. ;)

Le point 1 : ça dépend si le binaire est très gros (swap), ainsi que si les appels à la biblothèque sont fréquents ou non (elle peut se décharger).

Le point 2 : oui.

---

Je ne sais pas si en cas de swap, toute la DLL est déchargée ou bien si le système est plus futé et plus précis et qu'il ne dégage que les pages qui n'ont pas été utilisées depuis longtemps auquel cas, les pages du programme appelant peuvent aussi être dégagées au même titre que les pages de la DLL.

Quand je dis page, je parle bien d'entités de 4096 ou 8192 octets et pas de la DLL au complet.

Je rajouterai même qu'une DLL a plus de chance de rester en mémoire car elle risque d'être utilisée par d'autres programme (cela, c'est surtout vrai pour les DLL systèmes et probablement nettement moins vrai pour la DLL "ma_feature_a_moi_que_jai_fait.dll").

absolument. Bon on pinaille là ;)

Si par contre un inconvénient majeur des DLL :

il faut "shipper" la DLL avec le binaire.

(et sous sytème unixoide tout au moins il faut qu'elle soit physiquement au même endroit que quand on a compilé sur son propre système).

Par contre, avantage : si on a une modif à faire qui ne change pas les appels de fonctions, il suffit de la recompiler (et éventuellemnt la re-shipper) sans avoir à tout recompiler..

Citation:

---

Envoyé par souviron34

(et sous sytème unixoide tout au moins il faut qu'elle soit physiquement au même endroit que quand on a compilé sur son propre système).

---

T'as jamais utilisé un "unixoïde" toi :

Citation:

---

Envoyé par man ldconfig

ldconfig(8) ldconfig(8)

NAME
ldconfig - configure dynamic linker run-time bindings

SYNOPSIS
ldconfig [OPTION...]

DESCRIPTION
ldconfig creates, updates, and removes the necessary links and cache
(for use by the run-time linker, ld.so) to the most recent shared
libraries found in the directories specified on the command line, in
the file /etc/ld.so.conf, and in the trusted directories (/usr/lib and
/lib). ldconfig checks the header and file names of the libraries it
encounters when determining which versions should have their links
updated. ldconfig ignores symbolic links when scanning for libraries.

...

---

Ne raconte pas n'importe quoi....

Citation:

---

Envoyé par Tchetch

T'as jamais utilisé un "unixoïde" toi :

---

:mouarf: non.. juste depuis 17 ans ...

tu parles de .h..
Ce que tu indiques est pour la compilation.

Je te parle d'un binaire.

Quand tu "shippes" un binaire utilisant une bibliothèque dynamique, il te faut (comme sous Windows avec les .dll) shipper la .so correspondante..

OR il faut la mettre au même endroit physique (puisque le jump est dans le code).

Si donc sur ton système elle est dans /usr/lib, il faut qu'elle soit dans /usr/lib sur le système hôte.

Il n'est pas du tout évident que l'utilisateur ait les droits d'aller écrire dans ce répertoire. (remarque également valable pour la compilation proprement dite). En général, si tu peux la mettre dans /usr/lib, tout marche bien. MAIS si elle était dans /home/souviron/monprojet/lib, alors pas évident du tout...

Et c'est d'autant plus vrai si le "package" vient d'ailleurs, et que cela (l'installation) dépend de l'administrateur (par exemple les installations de X11 : des fois dans /usr/lib/X11R4.., des fois dans /usr/lib/X11/X11R4, des fois dans /usr/lib/X11 entre autres)

Contrairement au défaut de Windows, les unixoides sont multi-users depuis longtemps, avec différents droits...

Citation:

---

Envoyé par souviron34

tu parles de .h..

---

Euh... où ça?

Citation:

---

Ce que tu indiques est pour la compilation.

---

Tu sais, plus je lis, plus j'ai des doutes là-dessus...
Car la doc parle bien du loader, et pas du linker...

Et même les articles sur LD_LIBRARY_PATH (qui disent principalement qu'il ne faut pas l'utiliser pour un produit fini) parlent du loader et d'un changement run-time, pas compile-time...

D'un autre côté, des articles indiquent aussi qu'il y a bien un chemin hard-codé dans l'exécutable, comme tu l'as dit. Ces articles mentionnent également un utilitaire pour changer ces chemins. Par contre, ça parle beaucoup de Solaris, donc j'ignore si ça s'applique aussi aux autres OS...

Citation:

---

Envoyé par Médinoc

D'un autre côté, des articles indiquent aussi qu'il y a bien un chemin hard-codé dans l'exécutable, comme tu l'as dit. Ces articles mentionnent également un utilitaire pour changer ces chemins. Par contre, ça parle beaucoup de Solaris, donc j'ignore si ça s'applique aussi aux autres OS...

---

L'article parle de comment fixer le chemin dans l'exécutable au lieu de laisser le système faire le travail. Par défaut, ton système va chercher les librairies partagés dans diverses répertoires que tu as défini.

Le but étant de ne pas utiliser une variable d'environnement qui permet de spécifier d'autres chemins que ceux défini par défaut. Je n'ai lu que en vitesse, mais je vois très bien la sécurité comme étant une des raisons de le faire.

Citation:

---

Envoyé par Médinoc

Euh... où ça?

Tu sais, plus je lis, plus j'ai des doutes là-dessus...
Car la doc parle bien du loader, et pas du linker...

Et même les articles sur LD_LIBRARY_PATH (qui disent principalement qu'il ne faut pas l'utiliser pour un produit fini) parlent du loader et d'un changement run-time, pas compile-time...

---

Citation:

---

DESCRIPTION
ldconfig creates, updates, and removes the necessary links and cache
(for use by the run-time linker, ld.so) to the most recent shared
libraries found in the directories specified on the command line, in
the file /etc/ld.so.conf, and in the trusted directories (/usr/lib and
/lib). ldconfig checks the header and file names of the libraries it
encounters when determining which versions should have their links
updated. ldconfig ignores symbolic links when scanning for libraries.

---

:D

Citation:

---

Envoyé par Tchetch

L'article parle de comment fixer le chemin dans l'exécutable au lieu de laisser le système faire le travail. Par défaut, ton système va chercher les librairies partagés dans diverses répertoires que tu as défini.

Le but étant de ne pas utiliser une variable d'environnement qui permet de spécifier d'autres chemins que ceux défini par défaut. Je n'ai lu que en vitesse, mais je vois très bien la sécurité comme étant une des raisons de le faire.

---

ce qui veut bien dire ce que ça veut dire :P

C'est pourtant pas compliqué à comprendre ..

Le code d'une fonction d'une biblothèque statique est recopié dans l'exécutable à l'endroit de l'appel.

Le code d'une fonction d'une biblothèque dynamique est pointé dans l'exécutable (avec un jmp) à l'endroit de l'appel.

le chemin est donc en dur... (mais en langage machine).

Il suffit pour s'en rendre compte de déplacer une biblothèque dynamique à un autre endroit, et d'essayer de faire tourner le binaire...

(normalement, je crois que si c'est dans /usr/lib ça va chercher automatiquement, mais pas si c'est dans un sous-répertoire, et surtout pas si ça n'est pas sous /usr/lib).

Bon à priori on parle pas la même langue. Donc on va arrêter là.

1. Citation:

   ---

   Envoyé par souviron34

   (for use by the run-time linker, ld.so)

   ---

2. Citation:

   ---

   ldconfig checks the header and file names of the libraries it
   encounters when determining which versions should have their links
   updated.

   ---

   C'est ambigu, ça. Il peut aussi bien s'agir de l'en-tête du fichier, et non pas de fichiers d-en-tête.
3. Citation:

   ---

   ldconfig ignores symbolic links when scanning for libraries.

   ---

   Sur cette quote par contre, je ne vois pas trop le rapport avec le sujet...

Et aussi: http://unixhelp.ed.ac.uk/CGI/man-cgi?ld.so+8

Citation:

---

ld.so loads the shared libraries needed by a program, prepares the pro-
gram to run, and then runs it. Unless explicitly specified via the
-static option to ld during compilation, all Linux programs are incom-
plete and require further linking at run time.

---

Citation:

---

Envoyé par Médinoc

1. 
   Sur cette quote par contre, je ne vois pas trop le rapport avec le sujet...

---

Ben si..

Admettons que tu télécharges un soft qui a une .so.

Tu la mets chez toi, dans /home/Medinoc/package1

Soit tu définis (comme mentionné plus haut) le path, soit tu copies la biblio dans /usr/lib, soit il faut que tu crées le lien symbolique dans /usr/lib qui pointe sur ton répertoire.

Si par conséquent tu veux qu'un autre utilisateur y accède, il faut que soit il crée le path, soit il y ait au moins le lien symbolique.

D'où la possibilité pour toi d'écrire dans /usr/lib.

Et là, que ce soit pour la compil (pour que les autres aient accès à la même biblothèque), soit au runtime..

Si maintenant tu as créé ta biblio chez toi, et que tu as créé un lien symbolique dans /usr/lib, quand tu link, même avec ldconfig, il ne suivra pas le lien symbolique... (ce que dit la doc).

Il faudra donc, si tu shippes le binaire, que tu fasses créer par l'utilsateur un /home/medinoc/package1

Oui, ça j'avais compris, mais je ne vois pas pourquoi c'était un argument en faveur du "ldconfig, ça change le compile-time et pas le run-time".

Il faut voir la vérité en face, soit tu es passé pendant 17 ans à côté d'une feature clé du loader des unixoïdes, soit ça a été ajouté après que tu l'aies appris...

Citation:

---

Envoyé par Médinoc

Et aussi: http://unixhelp.ed.ac.uk/CGI/man-cgi?ld.so+8

---

Ce pointeur ne change rien à ce que disait Tchetch, c'est à dire définir le path à la main.... (variable d'environnement).

Mais pas automatiquement....

Citation:

---

Envoyé par Médinoc

Oui, ça j'avais compris, mais je ne vois pas pourquoi c'était un argument en faveur du "ldconfig, ça change le compile-time et pas le run-time".

Il faut voir la vérité en face, soit tu es passé pendant 17 ans à côté d'une feature clé du loader des unixoïdes, soit ça a été ajouté après que tu l'aies appris...

---

je remets ce que j'ai dit juste au dessus :

Citation:

---

Si maintenant tu as créé ta biblio chez toi, et que tu as créé un lien symbolique dans /usr/lib, quand tu link, même avec ldconfig, il ne suivra pas le lien symbolique... (ce que dit la doc).

Il faudra donc, si tu shippes le binaire, que tu fasses créer par l'utilsateur un /home/medinoc/package1

---

Il est tout à fait possible que je sois passé à côté de quelque chose, je ne suis pas omniscient :D

Mais encore une fois, dans ce cas précis, c'est une question de logique...

Si j'ai bien compris, ldconfig permet d'ajouter le répertoire de ton choix aux chemins des bibliothèques dynamiques.

Donc, si je déplace LibMedinoc.so, il suffit d'appeler ldconfig sur le répertoire de destination pour que tous les programmes dépendant de LibMedinoc.so marchent à nouveau...

Edit: Je précise "sans avoir à recompiler".

sur ta machine, oui. De même avec tes biblios (sans doute encore plus) :

tu as :

• une biblio1.so.
  
• une biblio2.a (ou .so) qui contient des appels à biblio1
  
• un prog qui contient des appels à biblo2.

Tu bouges biblio1.

ldconfig va aller modifer les répertoires dans l'exécutable de prog (arpès recompilation (linker)) et dans biblo2 pour refléter la nouvelle position.

Mais maintenant tu télécharges prog sur une autre machine. Il te faudra biblio1 au même endroit que sur la tienne, sauf si tu modifies le path à la main par la variable d'environnement.

Non, je parle bien de la machine de destination:

• Je copie prog là-bas.
• Je copie biblio1.so là-bas.
• J'appelle ldconfig sur l'exécutable où j'ai mis biblio1.so
  
  1. ldconfig met à jour ld.so.cache (et non pas prog)
• Je lance prog
  
  • Le loader charge biblio1.so pour exécuter prog.

(du moins, c'est ce que j'ai personnellement compris de l'article)

Par contre, j'admets qu'il faut sans doute être admin sur le poste de destination pour appeler ldconfig. Mais comme de toute façon, seuls les admins sont censés installer un programme...

EDIT : c'est possible que cela marche comme le dit Tchetch, MAIS (et c'est un gros mais), cela suppose d'une part d'avoir accès en écriture aux bibliothèques/exécutables/répertoires associés, et d'autre part l'intérêt est plus que limité...

Il est bien plus aisé d'avoir un mini-script "startprog.sh" qui va setter le chemin que d'aller modifier en dur...

Bref, en gros, l'argument est statique, plus gros mais autonome, dynamique, plus petit mais pas autonome ;)

Là-dessus, on est d'accord.

Je serais aussi du genre à ajouter "dynamique, plus facile à mettre à jour", mais ça n'est même pas toujours vrai, et beaucoup de gens oublient que si on fait un "breaking change", il est temps de donner un nouveau nom à la lib...