Citation:
Je rappelle à ce sujet qu'une classe exportée dans une DLL par un compilateur n'est utilisable que depuis du code fait par le même compilateur...
Ah ?
Citation:
Déjà, pourquoi ne pas les déclarer private ?
Même si elles sont exportées, elles seront inutilisables pour le code utilisant la DLL...
Mais j'essaie d'optimiser le code en fait. Si c'était aussi simple que de les déclarer en private, pourquoi se serait-on embêté à créer ces préfixe de visibilité ? Il est aussi question de symboles exportés, qui font grossir la taille des dll, et augmentent les risques de confusion.
J'ai aussi noté un exemple du lien de Klaim :
Code:
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
| #ifdef _MSC_VER
#ifdef BUILDING_DLL
#define DLLEXPORT __declspec(dllexport)
#else
#define DLLEXPORT __declspec(dllimport)
#endif
#define DLLLOCAL
#else
#ifdef HAVE_GCCVISIBILITYPATCH
#define DLLEXPORT __attribute__ ((visibility("default")))
#define DLLLOCAL __attribute__ ((visibility("hidden")))
#else
#define DLLEXPORT
#define DLLLOCAL
#endif
#endif
class DLLEXPORT SomeClass
{
int c;
DLLLOCAL void privateMethod(); // Only for use within this DSO
public:
Person(int _c) : c(_c) { }
static void foo(int a);
}; |
Dans ce code, si le compilateur est GCC, pas de soucis, privateMethod() n'est pas exportée. Maintenant si le compilateur est VC, on se retrouve avec le code suivant après expansion des macros :
Code:
1
2
3
4
5
6
7
8
| class __declspec(dllexport) SomeClass
{
int c;
void privateMethod(); // Only for use within this DSO
public:
Person(int _c) : c(_c) { }
static void foo(int a);
}; |
Et là privateMethod() est exportée ! Y a pas une erreur (à moins que VC n'exporte pas les données private) ? Un autre moyen de masquer privateMethod() comme je demandais aux posts précédents ?
J'ai encore poussé mes tests :
J'ai essayé la technique class __declspec(dllexport) MaClasse, au lieu de mettre le préfixe devant chacune des méthodes, mais j'ai plusieurs Warnings à la compilation du genre :
Citation:
SocketException.hpp|12|warning C4275: non dll-interface class 'std::exception' used as base for dll-interface class 'SocketException'|
Parce que la classe std::exception n'est pas déclarée exportée et que ma classe en hérite, ou encore :
Citation:
SocketException.hpp|23|warning C4251: 'SocketException::m_description' : class 'std::basic_string<_Elem,_Traits,_Ax>' needs to have dll-interface to be used by clients of class 'SocketException'|
(lien intéressant)
Parce que l'attribut (qui est protected) est un std::string et que std::string n'est pas une classe exportable ! VC essaie d'exporter les attributs de ma classe ? Pourquoi MinGW ne se plaint pas ?
