Qt dans DLL C++

**lesnakman** · 04/05/2009, 09h55

""

**Médinoc** · 04/05/2009, 13h55

Essaie comme ceci:

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
//Factory.cpp
#include <string>
#include "Factory.h"
#include "MyQt.h"

extern "C" DYNAMIQUE_API LibraryInterface* createInstance()
{
		return (new MyQt());
}

extern "C" DYNAMIQUE_API void deleteInstance(LibraryInterface *instance)
{
	delete instance;
}

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
#include <windows.h>
#include <iostream>
#include "LibraryInterface.h"

using namespace std;

typedef LibraryInterface* (*POINTEUR_FONCTION) (void);

int main(int &argc, char **argv)
{
    HINSTANCE DllInstance;
    POINTEUR_FONCTION createInstance = NULL;

    if ((DllInstance=LoadLibrary(TEXT("DllLibrary.dll")))!=NULL)
    {
     cout << "Load" << endl;
     createInstance = (POINTEUR_FONCTION)::GetProcAddress(DllInstance, "createInstance");
     
        if (createInstance != NULL)
        {
			cout << "Fonction Load" << endl;
			LibraryInterface *pMyQt;

			cout << pMyQt << endl;
			pMyQt= createInstance();

			cout << pMyQt << endl;
                       pMyQt->createWindow();
         }
        else
        {
            cout << "Fonction unload" << endl;
        }	

    //On libère la dll
    FreeLibrary(DllInstance);

    }else{
        cout << "Unload" << endl;
    }

    char pause;
    cin >> pause;
    return 0;
}

Si "createInstance" n'est toujours pas trouvé, essaie en le précédant d'un underscore dans l'appel à LoadLibrary().

**Twindruff** · 04/05/2009, 13h55

Il est normal le char* dans

Code :

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

typedef LibraryInterface* (*POINTEUR_FONCTION) (char*);

?

**bacelar** · 04/05/2009, 15h53

Le manque de portabilité entre compilateur C++ rend l'utilisation d'API C++ complètement illusoire.
Moi, j'utiliserais une API C avec un void* (un handler) comme premier paramètre qui sera un pointeur sur l'objet.

Résultats :
un complète compatibilité avec tout les compilateurs C/C++,
cloisonnement strict entre les C-Runtime das Dll,
utilisation par des languages non-objet
utilisation de la POO via le handle ( à la Win32)

**Médinoc** · 04/05/2009, 15h58

Rien n'empêche de créer des DLLs cantonnées à un seul projet, tu sais...

De plus, ensuite il y a des standards pour une meilleure portabilité au niveau objet, sous certains systèmes. Sous Windows, il y a COM (Component Object Model), qui marchera quel que soit le compilateur du moment qu'on respecte ses guidelines.

**bacelar** · 04/05/2009, 16h10

Une API COM est une API "Objet" language agnostique, et pas C++.

Déjà qu'ils ont du mal à gérer des types simples, imagine avec les types template pour la gestion de la durée de vie des références.

Une dll pour 1 projet, autant pas faire de dll. les dll sont faite pour être partagées et évolutives, sinon autant faire des librairies statiques.

**Médinoc** · 04/05/2009, 16h13

On peut toujours les partager entre plusieurs exécutables d'un même projet. C'est le cas à mon boulot, d'ailleurs.

**bacelar** · 04/05/2009, 16h24

A part obliger tous les exécutable à avoir les mêmes compilateurs et options de compilation ou encore d'être obligé de faire des compromis dans les configurations d'optimisations, je n'y vous aucun intérêt à part une très hypothétique diminution de taille de l'exécutable qui ne compensera pas le manque de performance au démarrage dû aux compromis d'optimisations.

Donc, à part pour montrer que c'est faisable dans un tout petit périmètre sans grands intérêts, à mon avis, cela ne sert qu'à faire trimer les débutants sur une voix sans issue.

**Médinoc** · 04/05/2009, 16h37

Envoyé par bacelar

A part obliger tous les exécutable à avoir les mêmes compilateurs et options de compilation

Facile quand tous les exécutables sont dans le même projet...

ou encore d'être obligé de faire des compromis dans les configurations d'optimisations, je n'y vous aucun intérêt à part une très hypothétique diminution de taille de l'exécutable qui ne compensera pas le manque de performance au démarrage dû aux compromis d'optimisations.

Je ne vois pas ce que tu veux dire pour "compromis d'optimisations"...

Donc, à part pour montrer que c'est faisable dans un tout petit périmètre sans grands intérêts, à mon avis, cela ne sert qu'à faire trimer les débutants sur une voix sans issue.

Là, je suis d'accord, le périmètre est petit, et ça n'est pas d'un grand intéret pour les débutants. La plupart du temps, si on veut un composant réutilisable en C++, autant le programmer directement en COM.

PS: Le projet sur lequel on bosse à mon boulot est basé sur MFC, contient 90 "projets" Visual 6, dont la moitié des applications. Ici, le code est correctement factorisé et réutilisé. Mais quand ça n'atteint pas cette échelle, on peut se limiter aux templates et bibliothèques statiques...

**bacelar** · 04/05/2009, 17h06

Je pense donc que nous sommes d'accord sur le fait que lesnakman ne devrait pas tenter de faire une API C++.

Facile quand tous les exécutables sont dans le même projet...

Pas si facile si nous avons beaucoup de projets dans une solution et que toute ou partie de la solution doit utiliser une nouvelle version du compilateur.
A moins d'être bloqué ad vitam aeternam sur une version antédiluvienne de VC6.

Je ne vois pas ce que tu veux dire pour "compromis d'optimisations"...

Quand on pousse assez loin l'optimisation, on cherche à rapprocher, grâce au profiling, les codes utilisés ensemble, donc plus il y a d'appelants, plus la probabilité d’avoir du code utilisés ensemble par tous les appelants est faible. Il faut faire des compromis pour que tous les appelant est une bonne performance mais pas la meilleur possible pour l'un des appelant. Chose que l'on peut faire pour chaque lib de chaque projet et nom sur les dll partagé par plusieurs projets.

Mais quand ça n'atteint pas cette échelle, on peut se limiter aux templates et bibliothèques statiques...

C'est justement qu'en ça atteint une certaine échelle qu'il ne faut pas être lié trop intimement avec le compilateur, pour pouvoir suivre l'évolution du compilateur par exemple.

**Médinoc** · 04/05/2009, 17h16

Oui, nous sommes d'accord.

En fait, on a porté toute la solution de VC++6 à VS2005 sans problème.
Mais on n'a pas fait d'optimisation cross-module (ni même de LTCG, c'est une honte).

**lesnakman** · 04/05/2009, 19h32

concernant le typedef LibraryInterface* (*POINTEUR_FONCTION) (char*);
C'était un oubli de ma part, car je compte creer différentes instances par la suite...

Merci pour ces réponses, je vais les lire avec attention.

**lesnakman** · 04/05/2009, 21h03

En faisant un static cast ça marche.

Code :

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

pMyQt= static_cast<MyQt* > ( createInstance() );

Je suis confronter à un autre problème.

Je dois pouvoir créer une fenêtre Qt:

Code :

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

1
2
 QApplication app(argc, argv);
 return app.exec();

Je dois donc insérer ce code dans ma DLL.(MyQt.cpp)

A partir de visual, comment je peux faire?

Il faut que j'utilise QtCore4.dll et QtGui4.dll. Je croyais qu'en les plaçant QApplication serait reconnu mais ce n'est pas le cas.

Quelqu'un a une idée?

Merci

**Médinoc** · 04/05/2009, 22h03

Envoyé par lesnakman

En faisant un static cast ça marche.

Code :

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

pMyQt= static_cast<MyQt* > ( createInstance() );

Ah non, ça n'est absolument pas "safe"!

Ton code client doit utiliser uniquement la classe abstraite LibraryInterface. Le code client ne doit jamais voir la classe dérivée!

**JolyLoic** · 04/05/2009, 22h26

Envoyé par bacelar

Je pense donc que nous sommes d'accord sur le fait que lesnakman ne devrait pas tenter de faire une API C++.

Je ne suis pour ma part pas d'accord avec cette idée. Quand on est sur un environnement où il y a suffisamment peu de compilateurs différents pour qu'on puisse :
- Soit faire une version pour tous les compilateurs/options de compilation majeures (sous visual studio, par exemple, seules 2 options posent souvent problème en pratique)
- Soit imposer aux personnes désirant travailler avec nous d'utiliser les mêmes compilateurs avec les mêmes options
- Soit un mix des deux solutions

Définir une API C++ ne pose pas de problèmes particuliers. Après, le choix DLL/lib statique est autre, et j'avoue réserver les DLL principalement aux systèmes de plug-ins.

Les alternatives ont un coût qui n'est pas négligeable pour un projet :
- Obligation de définir un wrapper autour de l'ensemble des classes d'interface, qui plus est dans un langage pas forcément très bien maîtrisé par les équipes, et souvent très basique.
- Difficultés d'utilisation de ce wrapper, justement parce qu'il est défini dans un langage basique qui ne fourni généralement pas de bons outils de gestion de la mémoire, qu'il a un modèle de gestion d'erreur différent du reste du code,...
- Baisse de performances causées par le wrapper, entre autre par la sérialisation/désérialisation de certaines structures de données qu'il demande.

**bacelar** · 04/05/2009, 23h35

Heu, mon alternative n'utilise aucun wrapper, est en C, ne propage aucune exceptions, ne definis que des code d'erreur, est compilateur indépendant.

**lesnakman** · 05/05/2009, 00h20

Médinoc...C'est vrai qu'en incluant le MyQt.h , je penses que ça ne respecterais plus le pattern factory.

**JolyLoic** · 05/05/2009, 00h56

Envoyé par bacelar

Heu, mon alternative n'utilise aucun wrapper, est en C, ne propage aucune exceptions, ne definis que des code d'erreur, est compilateur indépendant.

Si j'ai bien suivi, ta proposition est :

Moi, j'utiliserais une API C avec un void* (un handler) comme premier paramètre qui sera un pointeur sur l'objet.

On peut comprendre cette phrase de trois façons :
Soit : Tu as une seule fonction qui ressemble à ce que tu indiques, et de l'autre côté, tu vas caster le void* en quelque-chose qui a plus de sens pour l'utiliser. Dans ce cas, on n'est pas indépendant du compilateur, on doit avoir le même avec les mêmes options des deux côtés, ou une ABI compatible, pour que le cast donne quelque-chose qui a du sens.

Ou bien : Tu as toute une série de fonctions en C prenant un premier paramètre un handler, et qui reprennent grosso-modo l'interface publique de l'objet. Là, on devient indépendant du compilateur, mais cette série de fonction constitue un wrapper, et comme il est écrit en C, il est difficile à utiliser correctement (pas d'argument de type string, mais des char*, par exemple).

Ou bien : L'ensemble de ton programme est en C, et là, d'accord, tu n'es plus dépendant du compilateur, et tu n'as pas écrit de wrapper.

Sur l'aspect "ne propage aucune exception", en est tu certain ? Sais-tu que selon les compilateurs/les options de compilation les exceptions C++ peuvent ou pas être propagées à travers une couche C ? De plus, moi, ce qui m'intéresse, c'est justement que ces exceptions soient propagées. Quand j'ai du code qui wrap du code C++, je passe mon temps à catcher les exceptions dans ce code, générer une erreur selon un mécanisme approprié au wrappeur, et restituer les exceptions de l'autre côté du wrapper.

**bacelar** · 05/05/2009, 09h37

Le sens de ma phrase correspond à la deuxième alternative.
La difficulté d'utilisation est toute relative par rapport aux problèmes de gestion des C-Runtimes, mangling etc...
Le "wrapper" est quasi-transparent au niveau performance.
Une bonne interface est une interface avec peu de méthode donc une surcharge de travail assez faible.

L'inclusion de MyQt.h montre bien que le cloisonnement n'est pas maîtrisé et que le résultat sera une jungle inextricable qui s'écroulera à la première dll qui ne respectera des pré-requis mal maîtrisés.

**Médinoc** · 05/05/2009, 10h19

Les exceptions ne sont pas propagées pareil d'un compilateur à l'autre, elles ne sont donc pas censées être autoriser à franchir la barrière d'une DLL portable.

Bien sûr, dans le cas d'une DLL non-portable comme les DLLs d'extensions MFC dans une solution de 90 projets, cette contrainte est relaxée.

Qt dans DLL C++

Threads & Processus C++

Discussions similaires

Partager

Partager