Discussion :

[Xahell]

Bonjour � tous

J'ai un petit soucis qui m'emb�te depuis plusieurs jours :

Je cr�e une petite biblioth�que qui se pr�sente actuellement sous la forme d'une biblioth�que dynamique (dll pour window).

Donc, les classes et m�thodes sont lus dans la biblioth�que, c'est dynamique, tout �a tout �a.
Le petit probl�me, c'est que ma biblioth�que a une partie qui est devrait �tre en statique (template).

Je vais faire un petit exemple :

• Partie dynamique :
  • Classe A
  • Classe B
• Partie statique
  • Classe C (template)

Le probl�me, c'est que la classe C a pour attribute la classe A et la classe B.
Donc, le compilo va construire une classe C dans le projet ext�rieur, et va devoir y int�grer une classe A et une classe B.

Et l�, malheur ! Classe A et Classe B sont dynamiques !
Le compilateur est tr�s f�ch�. On lui a dit que les classes A et B sont dans une biblioth�que dynamique et voil� qu'il doit les int�grer dans le projet de fa�on statique pour la classe template C !

Et j'avoue que je ne vois pas du tout comment r�soudre �a.
En fait, la seule solution que je vois, c'est de compiler 2 fois les classes A et B. Une fois dans la biblioth�que dynamique et une fois dans la biblioth�que statique.

Qui plus est, je dois mettre les classes A et B statiques dans un nouveau namespace pour �viter les ambigu�t�s.

Voici donc ma question : existe-t-il une m�thode plus �l�gante � un tel probl�me ?

Je vous remercie d'avance pour toute r�ponse
Passez une agr�able journ�e

[3DArchi]

Bonjour et bienvenu sur le forum,
Peux tu montrer comment tu d�finis tes classes A et B. Je soup�onne un mic-mac sur les __declspec(dllexport)/__declspec(dllimport) ?

[EDIT]: je viens de faire un essai avec une DLL exportant une classe A, une classe B et int�grant une classe template ayant un membre A et B.
Je cr�e une application qui utilises A, B, la classe template instanci�e avec un int, la classe template instanci�e avec un A, la classe template instanci�e avec un B.... et tout fonctionne. D'o� le renforcement de mes soup�ons. Peux-tu montrer des exemples simplifi�s de ton A, B et de ta classe template qui reproduisent ton probl�me. Il faudra certainement aussi que tu jettes un coup d'�il sur les directives de compilation de tes 2 projets.

[Xahell]

Merci pour la bienvenue et merci pour l'aide

J'utilise Code::Blocks, donc pas de __declspec(dllexport)/__declspec(dllimport).

J'avoue �tre assez frustr� car je n'arrive pas � reproduire le bug en simplifi�.

Mais bon, la biblioth�que est imposante et il n'est pas �vident de comprendre la source de ce warning.

J'explique globalement, au cas o� un d�tail explirerait le bug sans que je le s�che.

La biblioth�que A utilise elle-m�me une autre biblioth�que B dynamique.

Lorsque l'on cr�e une classe template, elle sert � du polymorphisme pour la biblioth�que A (il s'agit d'�lements int�gr�s dans un graphe que l'on r�cup�re pour les manipuler). Le graphe se trouve dans la biblioth�que A.
Ces �l�ments manipulent des classes de la biblioth�que B.

Lorsque l'�l�ment int�gr� dans le graphe de la biblioth�que dynamique A est une classe template, il y a warning d'auto-importation.
Sinon, aucun probl�me.

Ce que je vais faire, en attendant de mieux comprendre pour pouvoir simplifier la chose.

Si quelqu'un est courageux, le temps que je comprenne mieux la source du probl�me pour l'arranger, il peut reproduire le bug.

Le code est simple :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
#include <Interface.hpp>
 
struct Element
{
    int variable;
};
 
int main()
{
    Interface _Interface;
    gui::Button Button = _Interface.Add<gui::Button>(); // Ok
    gui::List List = _Interface.Add<gui::List<Element> >(); // Warning
}

Je comprendrais que vous ne vous donniez pas la peine, c'est � moi de le faire apr�s tout Mais je suis un peu d�pass� et donc je risque de mettre un peu de temps � trouver l'erreur simplifi�e. Si vous soupsonnez l'origine bug, je vous invite � essayer, sinon ne vous donnez pas ce mal

Merci beaucoup quoiqu'il en soit ne serait-ce que pour votre patience.
Bonne soir�e � tous

edit : Je pense pas que le probl�me soit un probl�me de conception mais bien de param�tres de compilation. Le probl�me, c'est que je ne m'y connais pas du tout de ce c�t� l�. La seule chose que je comprends, c'est que je dois autoriser l'auto-importation. Et que --enable-auto-import ne fonctionne pas

[3DArchi]

Salut,
J'ai refais le m�me essai avec Code::Block et gcc qu'hier, et.... pas de probl�me !
Je penses comme toi qu'il doit y avoir un d�tail dans les options de compilation.
Peux-tu les pr�ciser (pour la DLL et pour l'appli)?

[koala01]

Salut, et bienvenue sur le forum.

M�me si tu travaille avec Code::Blocks, et quel que soit le compilateur utilis�, si tu veux cr�er une dll, tu dois pr�voir quelque chose ressemblant �

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
#if defined(BUILDLIB)
    #define EXPORTMYLIB __declspec(dllexport)
#else
    #define EXPORTMYLIB __declspec(dllimport)
#endif

et d�finir les fonctions export�es par la dll sous la forme de

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
EXPORTMYLIB void foo(/*paramètres éventuels */)
{
    /*...*/
}

Le but est que, lorsque tu compilera ta dll (il faudra avoir ajout� un -dBUILDLIB dans les options de compilation de la dll), le code soit remplac� par

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
__declspec(dllexport) void foo(/*paramètres éventuels */)
{
    /*...*/
}

et que, lorsque tu compilera un programme utilisant cette dll (o� -dBUILDLIB n'est pas ajout� dans les options de compilations du projet), le code soit remplac� par

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
__declspec(dllimport) void foo(/*paramètres éventuels */)
{
    /*...*/
}

Au final, lorsque tu compilera la dll, le code pr�viendra que la fonction est export�e, et, lorsque tu compilera ton application, le code pr�viendra que la fonction... se trouve dans la dll

NOTA: n'h�site pas � personnaliser BUILDLIB et EXPORTMYLIB de telle mani�re � ce que chaque dll ait ses propres termes

[3DArchi]

Salut, et bienvenue sur le forum.

M�me si tu travaille avec Code::Blocks, et quel que soit le compilateur utilis�, si tu veux cr�er une dll, tu dois pr�voir quelque chose ressemblant �

gcc m'exporte par d�faut tous les symboles du projet DLL sans avoir � les pr�fixer par quoique ce soit et sait ensuite les importer sans probl�me. (Je n'ai pas fait le test, mais j'imagine que si je fait des variables globales/fonctions libres statiques, il ne va pas les exporter.)

[EDIT] Exemples de fichier (c�t� DLL):
a.h :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
#ifndef A_H
#define A_H
 
 
class A
{
public:
   A(void);
   ~A(void);
};
 
#endif

a.cpp

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
#include "A.h"
#include <iostream>
 
A::A(void)
{
   std::cout<<"coucou d'un A"<<std::endl;
}
 
A::~A(void)
{
   std::cout<<"byebye d'un A"<<std::endl;
}

Cot� application :
main.cpp

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
#include "A.h"
 
int main()
{
   A a;
	return 0;
}

[Xahell]

Exact, Code::Blocks rejette tout __declspec(dllexport)/__declspec(dllimport) lors de la compilation ou de l'utilisation de la biblioth�que.

Petite note que j'ai oubli� : la biblioth�que utilise deux variables statiques. La classe template et ses attributs les utilisent. C'est le plus gros soupson que j'ai d'un point de vu de conception.
Mais je n'ai rien r�ussi � reproduire en simplifi� avec des variables statics qui donne le warning. Ce qui me laisse perplexe

Pour la compilation de la biblioth�que :

create import library - ok
create .DEF exports file - ok

A part �a, il n'y a que les options pas d�faut

Je n'ai pas le temps de m'y appliquer aujourd'hui, mais demain je reproduirais point par point la biblioth�que en simplifi� jusqu'� optenir le warning.
A partir de l�, �a sera plus facile pour vous de m'expliquer l'origine du probl�me

Je vous remercie beaucoup pour votre aide, encore une fois bonne journ�e � tous

[koala01]

Le probl�me, c'est que le propre d'une dll est d'�tre fournie pour tous les compilateurs...

cela implique que tu doit fournir un fichier d'en-t�te capable de s'adapter � ceux qui ont �ventuellement besoin d'un __declspec(dllimport)

De plus, m�me s'il ne prend pas en compte les instructions concernant les non exportations, C::B (et Gcc) fonctionnent tr�s bien avec l'utilisation des __declspec:

Cr�e un projet (dynamic link library), et tu remarquera qu'il te cr�e un fichier main.h qui contiendra, justement, les lignes

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
 
#ifdef BUILD_DLL
    #define DLL_EXPORT __declspec(dllexport)
#else
    #define DLL_EXPORT __declspec(dllimport)
#endif

d'un autre cot�, si tu cr�e un autre projet (shared library), tu cr�es un fichier nomm� (arbitrairement) buildlib.hpp et qui contient le code

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
#ifndef BUILDLIB_HPP_INCLUDED
#define BUILDLIB_HPP_INCLUDED
#if defined(BUILD_LIB)
    #define MYDLLEXPORT __declspec(dllexport)
#else
    #define MYDLLEXPORT __declspec(dllimport)
#endif
#endif // BUILDLIB_HPP_INCLUDED

que, dans les options du projet (project->build options ->onglet "compiler setting", sous onglet "defines"), tu d�fini BUILD_LIB tel quel (en �crivant simplement "BUILD_LIB" sans les guillemets) et qu'enfin, tu cr�es une classe sous la forme de
(MyClass.hpp)

Code :

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
 
#ifndef MYCLASS_H
#define MYCLASS_H
// je n'arrive pas à indiquer à C::B que le fichier
// dois d'office être inclu :P
#include <buildlib.hpp> 
class MYDLLEXPORT MyClass
{
    public:
        MyClass();
        ~MyClass();
        void foo();
    protected:
    private:
};
void foo();
#endif // MYCLASS_H

(fichier MyClass.cpp)

Code :

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
#include "MyClass.hpp"
#include <iostream>
/*MYDLLEXPORT*/ MyClass::MyClass()
{
    //ctor
}
 
/*MYDLLEXPORT*/ MyClass::~MyClass()
{
    //dtor
}
/*MYDLLEXPORT */ void MyClass::foo()
{
    std::cout<<"MyClass:: foo()";
}
void foo()
{
    std::cout<<"unexported foo()";
}

tant le compilateur que C::B s'adaptent tr�s bien aux __declpsec

Il n'y a pas non plus de probl�me si tu ne veux exporter qu'une fonction de classe, sous une forme proche de
(fichier Second.hpp)

Code :

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
 
#ifndef SECOND_HPP
#define SECOND_HPP
#include <buildlib.hpp>
 
 
class Second
{
    public:
        Second();
        virtual ~Second();
        static MYDLLEXPORT void foo(); //sinon cela n'a aucun sens
    protected:
    private:
};
 
#endif // SECOND_HPP

(fichier Second.cpp)

Code :

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
#include "Second.hpp"
 
#include <iostream>
Second::Second()
{
    //ctor
}
 
Second::~Second()
{
    //dtor
}
MYDLLEXPORT void Second::foo()
{
    std::cout<<"Second::foo()"<<std::endl;
}

et tu obtiens bel et bien uniquement les informations d�clar�es exportables dans le fichier def:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
EXPORTS
    _ZN6Second3fooEv @1
    _ZN7MyClass3fooEv @2
    _ZN7MyClassC1Ev @3
    _ZN7MyClassC2Ev @4
    _ZN7MyClassD1Ev @5
    _ZN7MyClassD2Ev @6

[Xahell]

Etrange, moi il me les a rej�t� (j'avais exactement comme ci-dessous).

J'ai d�t faire une bourde quelque part

Je pense avoir comprit pourquoi. J'avais d�clar� GUI-SFML pour ma macro. Et le '-' est pas bien vu.

J'avais pas fait attention

Je vais tester tout �a et je vous tiens au courant

edit : haha, �a marche ! Je n'ai plus de warning

je vous remercie infiniment pour votre aide Je viens d'apprendre plusieurs choses bien int�ressantes (et indispensable finalement) au passage.

Je vous souhaite � tous une agr�able journ�e