export class via dll probleme ?

salut,:D


Voici la classe à partir de laquelle je genère une dll...

J'utilise une méthode explicite pour importer la dll avec LoadLibrary
J'ai essayé de construire l'interface qui permet d'assurer la passerelle entre la dll (issue de la classe) et l'application mais le fait que j'utilise des types classes me pose problème

Pourriez-vous m'aider à finaliser mon interfaçe



voila la class :
class Param
{

Param();
~Param();

Param operator+(Param&);

void SetValue(double*);

Vector<double> GetValue();

vector <string> GetPath();

private :
vector <double*> _Value;
vector <string> _Path;
}



class Interface

class Param
{

virtual Param operator+(Param&);

virtual void SetValue(double*)=0;

virtual Vector<double> GetValue();

virtual vector <string> GetPath();


}

Merci d'avance ...

OuilleOuilleOuille...

Non seulement les DLLs n'aiment pas trop le C++, mais en plus elles détestent que la STL traverse la frontière!
J'ai essayé de faire une DLL avec ça mais il y avait tellement de restrictions supplémentaires que j'y ai renoncé...

Et en plus, pas moyen de retrouver sur MSDN l'article qui mentionnait ça...

j'ai réussi a faire qqchose du style, mais je ne sais pas si ca répondra exactement à ta question. jette un coup d'oeil sur ma calculatrice, dans le paragraphe "Calling the DLL" :

http://www.codeproject.com/cpp/VisualCalc.asp#CallDLL

je ne veux pas faire de pub pour un autre site, mais tu pourras récupérer les sources seulement si tu crées un compte.

Note surtout que tu dois compiler ta DLL et ton projet client en multithreaded (Debug) DLL, car le probleme vient du fait que certains objets instanciés par la DLL tentent d'etre détruis par le client...

Citation:

---

Envoyé par toxcct

Note surtout que tu dois compiler ta DLL et ton projet client en multithreaded (Debug) DLL, car le probleme vient du fait que certains objets instanciés par la DLL tentent d'etre détruis par le client...

---

C'est un peu douteux ça.

Utiliser des classes C++ dans des DLL n'est pas forcément trivial.

Il existe deux méthodes pour utiliser des DLL : la liaison statique ou la liaison dynamique (la dernière étant la méthode que tu essaies d'utiliser).

Tu peux déjà compiler tes DLL en les liant "statiquement" à ton exécutable (ou quelconque projet client). C'est à dire que lors de la compilation et l'édition des liens de ta DLL, deux fichiers seront créés : un .lib (bibliothèque statique) et un .DLL (ta bibliothèque dynamique).
Ensuite tu auras simplement à inclure le .lib généré dans le projet client. Ce .lib contient simplement les fonctions pour accéder aux objets de ta DLL.

Pour instancier et utiliser les classes dans ton projet client, il faudra que tu fournisses les en-têtes (.h) de tes classes à ton projet.

Dernier point, il faut rajouter __declspec(dllexport) ou __declspec(dllimport) dans la déclaration de ta classe (selon que tu exportes ou importes la classe).
Ainsi, lorsque tu compiles ta DLL, ta classe devra être déclarée dans ton .h :

Code:

---

1 2 3 4

class __declspec(dllexport) Param {... };

---

Dans ton projet utilisant les classes de ta DLL, tu devras utiliser un .h avec la déclaration :

Code:

---

1 2 3 4

class __declspec(dllimport) Param {... };

---

Ensuite, pour instancier Param dans ton projet, il suffira de faire comme d'habitude :
Param* param = new Param;


Note toutefois que l'utilisation de DLL peut amener certains problèmes difficiles à résoudre. Donc il est souvent préférable de réfléchir correctement à l'architecture des tes classes avant d'utiliser une DLL.
1. Un objet créé dans une DLL doit être détruit dans la même DLL. Si tu récupères dans ton exe une instance créée dans ta DLL, tu ne peux pas détruire cette instance dans ton exe. C'est pour cela que toxcct conseille de compiler ta DLL et ton projet client en multithreaded (Debug) DLL. Cela permet d'éviter ce problème (mais cela risque d'en poser d'autres si le projet client est compilé sur un autre compilateur que la DLL).
2. L'utilisation de la STL peux poser des problèmes. Si tu transmets des instance de conteneurs STL entre ton exe et ta dll (et inversement), il faut bien s'assurer que les deux versions de la STL soient bien identiques entre ton exe et ta DLL (cela est normalement le cas si tu compiles ton exe sur le même compilateur que ta DLL).



Maintenant il existe également la liaison dynamique de DLL à ton projet client. Dans ce cas plus besoin d'utilise le fichier .lib généré lors de la compilation de ta DLL. A la place il faut utiliser des fonctions du système pour lancer ta DLL. C'est la méthode LoadLibrary que tu sembles connaître.

Mais là c'est plus compliqué, puisque tu ne peux pas instancier directement une classe de ta DLL dans ton projet client. Il faut que tu créés une instance dans ta DLL et que tu la transmettes ensuite à ton projet, par l'intermédiaire d'une fonction exportée de ta DLL (ouf!). En général on utilise une architecture basée sur des interfaces pour ce cas.
Mais de toute façon, ce qui est expliqué plus haut (utilisation de __declspec(dllexport) ou __declspec(dllimport), fournir les en-têtes au client, etc.) reste également vrai pour la liaison dynamique.

En faisant des recherches sur Google à propos de LoadLibrary, tu devrais trouver des explications. Sinon je posterai un exemple plus détaillé.

Le problème n'est pas tant d'exporter des classes : C'est tout à fait possible, mais il me semble que seul un programme développé sous Visual pourra utiliser les fonctions C++ d'une bibilothèque développée sous Visual (car les conventions de nommage C++ sont propriétaires).

Le problème, c'est d'exporter des classes/fonctions qui ont des classes de la STL dans leur interface publique: fonctions qui prennent un conteneur en paramètre, retournent un conteneur, classes qui ont un conteneur en public:, etc.

Citation:

---

Envoyé par Médinoc

il me semble que seul un programme développé sous Visual pourra utiliser les fonctions C++ d'une bibilothèque développée sous Visual (car les conventions de nommage C++ sont propriétaires).

---

c'est a moitié vrai. en fait, les noms des objets sont effectivement décorés à la sauce MSVC, mais si dans le projet DLL du définit un fichier .def, il y a moyen de faire apparaitre proprement les symboles exportés ; malheureusement, je suis une bique sur ce sujet, donc je ne peux pas apporter plus d'info, ,mais je crois savoir que ca se fait.

Bonjour à tous et avant toute chose merci beaucoup de toutes vos réponses :)

Je profite de votre intérêt pour le sujet pour vous exposer un peu plus mon problème et peut-être que vous aurez d'autres idées pour en venir à bout.

J'ai développé une classe Param au sein de laquelle j'ai surchargé les opérateurs mathématiques standards. Pour faire simple, disons que j'ai en private de cette classe Nom et Données et en public les méthodes Get et Set qui permettent d'y accéder et bien évidemment la surcharge des opérateurs qui permettent d'effectuer des opérations sur 2 instances de la classe.

J'ai un programme dans lequel j'effectue nombre de traitements connus et que je peux compiler en espérant ne plus y toucher. Par contre j'ai une formule à résoudre qui elle est susceptible d'évoluer (si A et B sont des instances de la classe, je peux vouloir A+B ou A-B ou A*2/(4*B) ...) Dans un premier temps j’ai développé un interpréteur d'expressions mathématiques comme ça je passe un String au programme et il fait l'opération. Ma crainte est évidemment le temps de calcul car l'opération devra s'effectuer un nombre incalculable de fois avant la fin de la simulation. C'est pourquoi je me suis dit faisons une dll qui embarque la formule (et malheureusement la classe en question) à laquelle je ferai appel depuis mon exe. Vous connaissez la suite ...

Je ne suis pas développeur pro et à chaque fois que je pense régler un problème deux autres me tombent sur la tête c'est assez usant à la longue ...

Merci encore

Le problème, je l'ai décrit : C'est avec les conteneurs STL que ça coince.
Si tu peux les supprimer de l'interface de ta DLL (en passant en paramètre et en retournant de bêtes pointeurs vers tableaux + la taille, et en gardant tes vector en private), tu devrais pouvoir exporter tes classes et fonctions sans problème.

alors si tu écris un interpreteur, peut etre que tu peux sérieusement regarder ma calculatrice (cf un post un peu plus haut dans la discussion)...

moi, ,je n'ai pas plus d'idée pr ton pb, s'il n'est pas résolu. bon courage donc.