Discussion :

[Ange_blond]

Bonjour,

Voilà, j'ai un big projet de C++, basé sur des libs openSource.
Pour effectuer un travail, je dois exporter mon projet en DLL de maniere à mettre a disposition le code du projet, mais pas son contenu.

En d'autre mots, le projet n'est pas open source, mais il faut que je mette à disposition d'un autre projet MSVC les méthodes et classes que j'ai implémenté dans mon projet.
En gros, j'ai codé une boite à outils et je veux donc mettre a disposition les méthodes, mais pas leur contenu.


J'ai créé un projet vide avec quelques méthodes pour faire un essais et ça marche tres bien.


Probleme : je voudrais donc exporter mon projet en DLL (no pb) et le livrer avec les .h necessaire. Cependant, je ne peux pas livrer tous les .h, car nombre d'entre eux contiennent beaucoup de code. De plus livrer tous les header reviens à donner toute la structure du projet...

Sauriez vous s'il est possible dans un 1er temps, de ne pas livrer toutes les DLL, mais juste celles qu'on veut (et quelques dépendances nécessaires j'imagine) ?

Dans mes premiers essais, j'ai pleins de soucis de compilation au linker qui ne trouve pas les méthodes visiblement, malgré le .lib et tous les headers... (error LNK2019: symbole externe non résolu ...)
Vous auriez des idées ? des expériences ?

Merci.

[Ange_blond]

Bonjour,

J'ai progressé et j'ai enfin réussi à compiler un nouveau projet sur la base de la DLL.

a présent, je suis en train d'essayer d'épurer la liste des .h à devoir livrer avec la DLL, mais visiblement, il les faut presque tous !

Quel autre moyens a-t-on de livrer une DLL sans devoir livrer les header avec ?
Merci.

[Gabrielly]

Salut,
Sans les headers c'est impossible!!!
Le code client n'aura aucune référence de tes objets ou méthodes.

[Ange_blond]

Bonjour,

Le but c'est de mettre à disposition du code, en minimisant son "dévoilement" et en ne rendant accessible qu'une poignée de classes/méthodes.

J'ai tenté le classique DLL+.lib+headers, qui bien sur ne me convient pas.
J'ai aussi testé le link en explicit (charger directement la dll et récuperer les pointeurs de méthodes) ce qui marche tres bien mais reste problematique car lorsque je récupere une instance d'une classe de la DLL, il me faut son header pour acceder aux méthodes... et on retombe dans le probleme original.

J'ai vu qu'il existait 2 méthodes d'utilisation d'une DLL

cette méthode ci :
http://msdn.microsoft.com/en-us/libr...z7(VS.80).aspx semble ne necessiter que la DLL, sans rien d'autre... qqun a déjà essayé ? des avis sur cette méthode ?

merci.

[r0d]

Bonjour,

c'est un peu dangereux mais on peut faire ça via le "explicit runtime linking". Je ne l'ai jamais mis en pratique, donc je ne rentrerais pas dans les détails, mais en gros, une fois que ta dll est compilée, le code qui l'utilise va ressembler à cela (exemple pour windows):

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// supposons que ta dll fournit une fonction qui est déclarée ainsi:
// double AddNumbers( double a, double b );
 
#include <windows.h>
#include <iostream>
 
// dignature de la fonction de ta dll
typedef double (*importFunction)(double, double);
 
int main(int argc, char **argv)
{
	importFunction addNumbers;
	double result;
 
	// chargement de la dll
	HINSTANCE hinstLib = LoadLibrary(TEXT("madll.dll"));
	if (hinstLib == NULL) {
		std::cout << "ERROR: unable to load DLL" << std::endl;
		return 1;
	}
 
	// récupération d'un pointeur sur la fonction
	addNumbers = (importFunction)GetProcAddress(hinstLib, "AddNumbers");
	if (addNumbers == NULL) {
		std::cout << "ERROR: unable to find DLL function" << std::endl;
		FreeLibrary(hinstLib);
		return 1;
	}
 
	// appel de la fonction
	result = addNumbers(1, 2);
 
	// libératino de la dll
	FreeLibrary(hinstLib);
 
	return 0;
}

[Ange_blond]

Bonjour

J'ai ce code ci, et il fonctionne.

Il m'est donc possible d'appeler une fonction dans la ma dll.

Par contre, en terme de gestion objet, je peux créer une instance de classe depuis une méthode, mais je récupere donc un myClass*, et je ne peux pas utiliser le myClass en question, sans avoir un .h qui défini cette classe, meme si elle est déjà définie dans la DLL ... non ?

(heuu ce n'est peut etre pas tres clair, je vais préciser)

En gros, je veux non seulement apeller des méthodes de la DLL, mais aussi pouvoir instancier des classes. Comme je ne peux apeller que des méthodes, je fait donc une méthode qui me retourne un new myClass().
Je peux donc créer une instance de myClass depuis mon exe juste avec la DLL. Par contre, dans mon exe, le type myClass n'est pas défini, et donc je ne peux pas acceder à ses méthodes...

Une idée sur comment feinter ? je commence à secher sur la question petit à petit...

Merci.

[Ange_blond]

Bon, petit UP pour signaler que j'ai trouvé un moyen, certe peu glorieux, mais qui marche !

Je créé donc dans ma DLL une méthode qui me retourne un nouvelle instance de ma classe.

Depuis mon exe, j'appelle donc explicitement cette méthode que je récupere dans un myClass*. Le compilateur ne connait pas cette classe, je le feinte donc en déclarant la classe

Code :

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

class myClass;

en début de fichier.

Ainsi le compilo connait le type, mais pas les méthodes.

Ensuite, pour acceder aux méthodes de la DLL, je créé dans la DLL une méthode qui prend en parametre mon instance de myClass et qui fera donc les appels depuis cette instance sur les fonctions membre de mon choix. Comme dans la DLL myClass est bien défini, alors tout roule

La limite de la chose est bien sur qu'il faut redéfinir dans la DLL un certain nombre de fonctions pour permettre d'acceder aux méthodes membre, mais visiblement ça marche plutot bien.

Je n'ai pas encore aboutit mon codage, mais j'ai enfin réussi à lancer mon code de la DLL sans .h ni rien d'autre que ma simple DLL.

Toujours à la recherche d'autre moyens plus "clean" bien sur, mais en attendant j'ai un résultat.

Merci.

[Nogane]

Bonjour,
Une solution serait peut-être de réencapsuler tes classe pour en cacher l'implémentation, comme expliqué ici:
http://bruce-eckel.developpez.com/li...ntation#L5.6.2
ou ici:
http://www.gotw.ca/gotw/028.htm

Ainsi tu aura surement moins de header a fournir. Et des header plus petit.

[Ange_blond]

C'est en effet une solution potentielle, et c'est aussi ce que j'utilise déjà, du mois en partie.
Je me base sur la déclaration de classe pour ne pas avoir besoin du header complet.

Je vais voir si l'appliquer sur le code de ma DLL peut suffire à ce que je veux, auquel cas c'est en effet plus propre comme méthode.

Merci.