Discussion :

[shinigami]

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

[3DArchi]

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?

[shinigami]

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

[3DArchi]

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.

[shinigami]

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.

[3DArchi]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[DLL] Interface.c

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
int min(int i1_, int i2_)
{
   return (i1_<i2_)?i1_:i2_;
}

[Application] Dialog.c (exemple):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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);
   /* ... */
}

[shinigami]

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

[souviron34]

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.

[ram-0000]

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.

[souviron34]

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.

[ram-0000]

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").

[souviron34]

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..

[Tchetch]

(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 :

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.

...

[souviron34]

Ne raconte pas n'importe quoi....

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

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...

[Médinoc]

tu parles de .h..

Euh... où ça?

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...

[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...

[Tchetch]

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.

[souviron34]

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...

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.

[souviron34]

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

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).

[Tchetch]

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