Discussion :

[NiamorH]

Bonjour,

Une classe ainsi définie peut-elle poser des problèmes à l'utilisation dans un code client ? Si le compilateur n'est pas le même ou si la dll de la crt est différente (je dis peut-être des conneries car je maîtrise pas du tout) ?

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
#include <memory>
#include "Export.h"
 
class B;
 
class A_EXPORT A
{
public:
	A( std::auto_ptr<B> b );
	~A();
 
private:
	struct C;
	std::auto_ptr<C> c_;
};

Merci

[Montag]

Salut,

Tu devrais lire cet article qui explique très bien pourquoi ce que tu veux faire est dangereux. En général les fonctions exportées par une dll ne prennent que des types primitifs en paramètre et ont un linkage C (pour éviter, entre autres, les problèmes de mangling).

[NiamorH]

Effectivement c'est très intéressant et cela répond très bien à ma question.

Du coup ça limite vraiment l'utilisation des DLLs C++ avec export d'objets. En gros il faut avoir également les sources à disposition pour pouvoir les compiler avec des settings identiques au projet client.

[Médinoc]

En effet.
C'est pourquoi la plupart du temps, pour faire une DLL orientée objet, on fait des DLLs COM (ou on programme pour le Framework .Net).

Évidemment, l'utilisation de bibliothèques comme Microsoft Foundation Classes (MFC) ou Active Template Library (ATL) est une exception, puisque MFC et ATL ne sont compatibles qu'avec Visual Studio. Même si en général, il est quand même conseillé de limiter les DLLs MFC au même projet.