Discussion :

[Ghurdyl]

Bonjour,

J'écris une petite bibliothèque j'ai 2 classes dedans :

Code layer_part.h :

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
#pragma once
 
#include <string>
#include <vector>
#include "Polygon.h"
 
class __declspec(dllexport) Layer_part
{
private:
	std::string _filter;
	int _order;
	std::vector<Polygon> _vectPoly;
public:
	Layer_part(void);
	Layer_part(std::string expr_filter, int order);
	~Layer_part(void);
 
	void addPolygon(int fill_color, std::string column_filter, int order);
};

et

Code Polygon.h :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#pragma once
 
#include <string>
 
class __declspec(dllexport) Polygon
{
private:
	int _color;
	std::string _filter;
	int _order;
public:
	Polygon();
	Polygon(int fill_color, std::string column_filter, int order);
	~Polygon(void);
};

à la compilation, la déclaration du vecteur donne les erreurs suivantes :

- error C2923: 'std::vector'*: 'Polygon' n'est pas un argument de type modèle valide pour le paramètre '_Ty'

- warning C4251: 'Layer_part::_vectPoly'*: class 'std::vector<_Ty>' nécessite une interface DLL pour être utilisé(e) par les clients de class 'Layer_part'

Je ne comprend pas

[Ghurdyl]

Bon,

Pour l'erreur, je l'ai corrigée en renommant ma classe "Polygon" en "Polygon_data".
Il y avait sans doute un conflit de nom mais pourquoi alors n'ai-je pas eu plutôt une erreur du type "ambiguous symbol" ...
bref.

Pour les warnings, j'ai lu plusieurs choses mais j'en comprend trop peu que pour pouvoir les résoudres proprement.
De plus j'ai lu qu'elle peuvent donner lieu à de sales problèmes à l'exécution

[nicroman]

Pour les warnings, c'est simple:

std::vector n'est pas dans une dll, mais une librairie....
Si ta DLL est compilée avec la std 7.2, le std::vector aura une certaine signature.
Si un EXE utilisant ta DLL compile avec la std 8.0, le std::vector pourrait avoir une autre signature... => bug, crash et consorts

Il n'existe que deux moyens propres de passer outre ce warning:

1. Rendre cette instance particuliere de std::vector implémentée / exportée de ta DLL:
template __declspec(dllexport) std::vector<Polygon>;
A noter qu'il faudra faire de même avec std::string

2. Cacher l'implémentation (et donc l'utilisation de std::string & std::vector)
Ca se fait dans une classe 'Data' non exportée, et visible seulement depuis l'intérieur de ta DLL;
Bien sur, il en va de même pour les paramètres, de toute manière, passer un std::string en paramètre d'une fonction....

Ensuite, attention de ne pas utiliser __declspec(dllexport), mais bien une macro qui fera soit export soit import selon qu'on compile la DLL ou qu'on l'utilise !

[Ghurdyl]

Bonjour,

Merci pour ta réponse.

Tout ceci est assez nouveau pour moi et je voudrais être sûr de bien comprendre.

Ce que tu me suggères, c'est donc de faire c'est :
Soit de déclarer mon vecteur comme ceci

Code :

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

__declspec(dllexport) std::vector<Polygon> _vectPoly

Soit de regrouper mes variables d'instances provenant de la std:: dans une classe "invisible de l'extérieur" et de la mettre cette classe en variable d'instance de ma classe Polygon

En ce qui concerne la macro, dois-je la faire dans les 2 cas ?
Je n'ai jamais écris de macro, peux-tu me donner un exemple ou à défaut un lien vers un exemple ?.

Un grand merci

[koala01]

Bonjour,

Merci pour ta réponse.

Tout ceci est assez nouveau pour moi et je voudrais être sûr de bien comprendre.

Ce que tu me suggères, c'est donc de faire c'est :
Soit de déclarer mon vecteur comme ceci

Code :

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

__declspec(dllexport) std::vector<Polygon> _vectPoly

Soit de regrouper mes variables d'instances provenant de la std:: dans une classe "invisible de l'extérieur" et de la mettre cette classe en variable d'instance de ma classe Polygon

Oui, c'est bien cela... ou dans tout endroit non exporté où le std::vector<Polygon> serait opportun

En ce qui concerne la macro, dois-je la faire dans les 2 cas ?

Oui, parce que l'exportation doit avoir lieu lors de la compilation et que l'importation de la dll doit avoir lieu lorsque tu utilise la dll...

Tu pourrais aussi t'amuser à écrire deux en-têtes différents (l'un pour la compilation qui utilise dllexport et l'autre pour l'utilisation qui utilise dllimport), mais c'est se faire du mal inutilement

Je n'ai jamais écris de macro, peux-tu me donner un exemple ou à défaut un lien vers un exemple ?.

il suffit de demander: regarde ma prose dans cette discussion

Tout y est indiqué

[Ghurdyl]

D'accord merci

c'est tout à fait clair maintenant

merci beaucoup