Discussion :

[vandamme]

Voila, j'ai un projet qui utilise log4cxx.
Lorsque j'exécute mon programme sous VS2005 en mode Debug, je dois utiliser la libraire :
D:\Program\apache-log4cxx-0.10.0\projects\Debug\log4cxx.dll
Par contre, si j'execute en mode Release, je dois utiliser la libraire :
D:\Program\apache-log4cxx-0.10.0\projects\Release\log4cxx.dll

La question est que je peux pas mettre dans le PATH Windows a la fois
D:\Program\apache-log4cxx-0.10.0\projects\Debug\log4cxx.dll
et
D:\Program\apache-log4cxx-0.10.0\projects\Release\log4cxx.dll

Alors comment faire pour que a l'exécution dans Visual, ce soit la bonne librairie qui soit choisie selon que je suis en Debug ou Release ?
Bien sur, je peux toujours copier la bonne version de log4cxx.dll dans Release ou Debug mais ca me semble un peu sale comme méthode ...

[Laurent Gomila]

La bonne solution aurait été que cette bibliothèque ait un nom différent en version debug. A partir de là, je ne vois a priori pas d'autre solution que celle que tu proposes.

[nicroman]

1. On ne met pas de DLL dans le 'PATH' windows. Cette façon de lier un executable à une DLL date de Mathusalem. Même remarque pour le répertoire Windows (qui d'ailleurs, est normalement interdit d'accès).
Il y a deux possibilités pour lier un executable à une DLL:
- Rajouter la DLL dans les chemins de l'executable dans le registre
- Coller la DLL à coté de l'executable.

2. Je vois pas pourquoi tu *dois* utiliser la version debug de log4cxx... A moins que tu ne veuilles la débugger bien sur
Utiliser la version release, ne changera rien, sauf qu'elle sera plus rapide, plus petite, etc... A moins, encore une fois, que tu ne veuilles débugger log4cxx.

3. Pour faire ce que tu veux faire, tu peux:
- Créer le répertoire debug/release de ton projet (là ou Visual va linker le .exe), et y coller les DLLs.
- Rajouter les DLLs dans ton projet (ailleurs), et effectuer (à la compilation) une copie de la DLL vers le répertoire destination de compilation (pas le temporaire). Rassures toi, la copie n'aura lieu que quand la destination ne correspond pas à la source (vive Make ! )

[Spout]

Dans Windows, Microsoft a pour habitude de livrer les deux versions dans le même répertoire sous deux noms légèrement différents : malib.lib pour la version release et malibd.lib pour la version debug (sans parler du 'u' en plus pour les versions unicode = 4 versions pour la même bibliothèque ).
Je trouve que c'est une assez moche idée, car il faudrait à terme que tu ajoutes les chemins de toutes les librairies que tu utilises sur un même poste à la variable d'environnement PATH. Je trouve ça un peu lourd.
Le mieux reste quand même de copier la DLL avec l'exécutable. Attention toutefois à garder la maitrise de quelle(s) DLL est où.
Le meilleur mieux est encore le linker la librairie statiquement, mais ça n'est pas toujours possible.

J'ai pris pour habitude, lors de la création d'une solution Visual, d'ajouter un répertoire BIN dans lequel sont placées toutes les sorties de chaque projet (déplacement de la sortie du projet). Ca permet de tout faire sortir au même endroit, et de pas avoir x copies d'un même fichier dans la solution.

2. Je vois pas pourquoi tu *dois* utiliser la version debug de log4cxx... A moins que tu ne veuilles la débugger bien sur
Utiliser la version release, ne changera rien, sauf qu'elle sera plus rapide, plus petite, etc... A moins, encore une fois, que tu ne veuilles débugger log4cxx.

Je dirais bien ça aussi, mais un coin de ma mémoire me fait tilt sur une mauvaise expérience que j'aurais eu. Mais bien sûr je n'arrive pas à remettre la main dessus ...

[Laurent Gomila]

Pour ce qui est de l'utilité de lier la version debug en debug.
Il peut être utile de ne pas mixer versions debug et release, notamment s'il y a utilisation explicite de la bibliothèque standard et/ou allocations mémoires, car dans ce cas ce n'est pas la même version de la CRT qui est liée côté programme et côté bibliothèque, ce qui provoque la plupart du temps des crashs.

[nicroman]

tssss tssss ....

Si il y a utilisation explicite de la librairie standard, alors deux librairies (compatibles) cohabiteront...
Pour ce qui est des allocations mémoire... si la DLL alloue de la mémoire c'est à elle de la libérer... donc, si log4cxx est bien programmée, il ne devrait pas y avoir de mixage mémoire (sinon ca serait l'horreur avec nos Memory Manager )

[Laurent Gomila]

Si il y a utilisation explicite de la librairie standard, alors deux librairies (compatibles) cohabiteront...

Et il se passe quoi si dans la version debug de ma lib standard std::vector a des membres supplémentaires, lorsque je vais appeler une fonction de la bibliothèque qui renvoie un std::vector compilé en release ?

[nicroman]

C'est bien pour ça que les classes "standards" (de la STL) sont rarement passés (exposés) d'une DLL à une autre... Il se passerait quoi si deux DLLs utilisaient des objets incompatibles (sans parler de debug/release, mais simplement de version !) de la stl ?

Non, si la DLL est bien faite, il n'y a rien à craindre de ce côté là.

[Laurent Gomila]

Je suis d'accord, mais le problème c'est qu'on est dans ce cas aussi si on a simplement un conteneur standard en donnée membre privée d'une classe exportée. Et ça, difficile de l'éviter.

[nicroman]

Si en cachant l'implémentation...
De toute manière Visual va afficher de gros warnings dès qu'une classe non exportée (comme un template) est membre d'une classe exportée.
Il y a deux moyens de résoudre le problême: exporter la spécialisation du template, ou... cacher l'implémentation (qui est probablement la solution la plus élégante).