"lib statique" vs "lib dynamique" vs "objet COM"

Bonjour,

Je vais me lancer dans le développpement d'un composant de génération des messages de log. Je dis composant dans un premier temps pour rester générique et global.

Ce composant sera utilisé par les différents programmes que je développe (en attendant qu'il soit utilisé par le monde entier :P). Ces programmes sont tous indépendants les uns des autres même s'ils tournent souvent autour du même sujet (projets différents).

J'ai déjà une très bonne idée de ce qu'il fera et de comment il le fera mais par contre, je me pose encore des questions au sujet du mode d'interface entre le programme utilisateur et ce composant.

J'ai actuellement plusieurs pistes pour l'implémentation de l'interface :

• Composant dans une librairie statique (.h + .lib)
• Composant dans une librairie dynamique (.h + .lib + .dll)
• Composant dans un objet COM (là j'avoue que je ne maitrise pas encore le sujet)

Chaque méthode a ses avantages et ses inconvénients et je ne sais pas encore choisir donc si vous aviez un éclairage à apporter ou des conseils, ils seraient les bienvenus.

Déjà, je pense qu'il te faut une DLL plutôt qu'une lib statique, car tu devras sûrement partager des choses (comme le fichier de sortie) entre les différents "modules" (dlls, exes) qui utiliseront ta bibliothèque de log.

Ensuite, ça dépend de la façon de l'utiliser: Si c'est plutôt "à la C++", je te conseille d'en faire un objet COM (sans en faire nécessairement un composant COM, qui s'enregistre et tout). Si c'est plus simple, une DLL avec interface C __stdcall.
Ce que je te déconseille en tout cas, c'est une DLL avec une interface C++ non-COM.

Ensuite, il faut savoir si tu veux la jouer "facultatif". Si tu veux pouvoir utiliser un objet de log nul, je te conseille la bibliothèque avec interface C, car un pointeur COM est systématiquement déréférencé (pour lire la vtable).

Citation:

---

Envoyé par Médinoc

Si c'est plutôt "à la C++", je te conseille d'en faire un objet COM (sans en faire nécessairement un composant COM, qui s'enregistre et tout).

---

Je ne saisi pas la différence dans ta remarque entre objet COM et composant COM ?

Citation:

---

Envoyé par Médinoc

Si c'est plus simple, une DLL avec interface C __stdcall.

---

C'est une DLL avec des fonction "C pures" qui peut s'appeler indifféremment depuis le C ou le C++ (ou d'autres langages) quelque soit le compilateur ?

Citation:

---

Envoyé par Médinoc

Ce que je te déconseille en tout cas, c'est une DLL avec une interface C++ non-COM.

---

C'est une DLL qui exporte des objets C++ avec le "Name mangling" du compilateur qui a généré la DLL. Cette DLL ne peut s'appeler que depuis du C++ en respectant le "Name mangling" de la DLL ?

Citation:

---

Envoyé par Médinoc

Ensuite, il faut savoir si tu veux la jouer "facultatif". Si tu veux pouvoir utiliser un objet de log nul

---

Je ne saisi pas ta remarque

Citation:

---

Envoyé par ram-0000

Je ne saisi pas la différence dans ta remarque entre objet COM et composant COM ?

---

Disons que pour moi, le terme "composant" implique la présence d'un CLSID, d'une ClassFactory, et d'un enregistrement dans la base de registre. À l'inverse le "simple objet COM" peut être crée juste en exportant une fonction CreateXxxxx() dans la DLL...

Citation:

---

C'est une DLL avec des fonction "C pures" qui peut s'appeler indifféremment depuis le C ou le C++ (ou d'autres langages) quelque soit le compilateur ?

---

Oui, mais ça peut aussi être en C++ avec juste une interface C (voir extern "C")

Citation:

---

C'est une DLL qui exporte des objets C++ avec le "Name mangling" du compilateur qui a généré la DLL. Cette DLL ne peut s'appeler que depuis du C++ en respectant le "Name mangling" de la DLL ?

---

Oui, c'est ça.

Citation:

---

Je ne saisi pas ta remarque

---

Si tu fais des fonctions avec interface C, tu peux faire en sorte qu'elles acceptent un pointeur nul quand tu ne veux pas de log.
Exemple:

Code:

---

1 2 3 4 5 6 7 8

extern "C" void LogguerUnTruc(Logger *, char const *);   void MaFonctionQuiBiduleUnMachinEtQuiLoggue(Logger *pLogger, Machin *pMachin) { LogguerUnTruc(pLogger, "Begin bidule"); Machin->bidule(); LogguerUnTruc(pLogger, "End bidule"); }

---

Avec un tel code, tu peux toujours implémenter la fonction LogguerUnTruc() de manière à ne rien faire si on lui passe un pointeur nul.
Ce que tu ne peux pas faire si tu es 100% en COM :

Code:

---

1 2 3 4 5 6

void MaFonctionQuiBiduleUnMachinEtQuiLoggue(ILogger *pLogger, Machin *pMachin) { pLogger->LogguerUnTruc("Begin bidule"); //Echec si ptr nul Machin->bidule(); pLogger->LogguerUnTruc("End bidule"); }

---

Si tu veux que tes fonctions acceptent un objet nul, tu te retrouves obligé de rajouter un test if(pLogger!=NULL) à chaque fois (ou à passer par des fonctions/macros qui contiennent le test, ce qui peut être une bonne option).