Discussion :

[salseropom]

Bonjour, je fais une librairie. Certaines des fonctions sont templates, donc je dois les mettre dans un .h.

Quand je livre ma librairie � mon client, je lui fournis une doc, le .dll, le .lib et tous les .h contenant les d�clarations des fonctions.

Le souci, selon moi, est que je ne veux pas qu'il voit le code source (de toutes les fonctions templates qui sont dans les .h).

Savez-vous comment faire ? Je suis sous Visual 2005 et linux (sous linux : compilo g++)

Merci d'avance

[koala01]

Salut,

La premi�re question qui me vient � l'esprit, en lisant ta question, est "pourquoi faire"

Je peux comprendre que tu souhaite prot�ger un minimum la paternit� de ton code, mais, de mani�re g�n�rale, j'ai quand m�me quelques doutes sur le fait qu'il soit � ce point "r�volutionnaire" pour valoir la peine d'�tre tout � fait cach� (comprend: d'avantage que par la simple compilation)...

Ceci dit, j'ai une bien mauvaise nouvelle pour toi: d�s le moment o� tu travailles avec des templates, il devient purement et simplement impossible de cacher le code source, si, du moins, tu souhaites permettre � l'utilisateur d'utiliser les fonctions (et les structures) template en tant que telles:

En effet, l'impl�mentation binaire (ex�cutable) d'un template d�pendra principalement du type d'objet manipul� r�ellement, ce qui implique qu'elle doit �tre cr��e par le compilateur chaque fois qu'une fonction (ou qu'une structure) est utilis�e avec un type particulier, avec pour cons�quence que le compilateur a besoin de disposer du code source correspondant.

Si, maintenant, tu n'utilise les fonctions et structures template que de mani�re interne, il est toujours possible d'envisager de s�parer l'impl�mentation de la d�claration, en pla�ant, par exemple, la d�claration de fonction template ou la d�finition de structure tempalte dans un fichier d'en-t�te (*.h / *.hpp), et l'impl�mentation des fonctions (membres) dans un fichier s�par�, d'extension libre (*.impl pour implementation ou .tpp )

Il faudra alors veiller:

1. A ce que l'utilisateur de ta biblioth�que ne soit pas tent� d'utiliser la structure ou la fonction template (ce qui implique de ne pas fournir le fichier d'en-t�te � ton client)
2. A inclure, dans tout fichier utilisant la structure ou la fonction template, non seulement le fichier d'en-t�te, mais �galement le fichier d'impl�mentation associ�.

Cela pourrait donc prendre une forme proche de
fichier mytemplate.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 MYTEMPLATE_H
#defineMYTEMPLATE_H
template <class T>
class MyTemplate
{
    public:
        /*...*/
        void foo();
};
template <class T>
void bar();
#endif // MYTEMPLATE_H

fichier mytemplate.impl

Code :

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

1
2
3
4
5
6
7
8
9
10
11
#include <mytemplate.h>
template<class T>
void MyTemplate<T>::foo()
{ 
    /*ce qui doit être fait */
}
template <class T>
void bar()
{
    /* ce qui doit être fait */
}

fichier somefile.cpp

Code :

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

1
2
3
4
5
6
7
8
9
10
#include <mytemplate.impl>
void doSomething()
{
    MyTemplate<int> ...
 
}
void doOtherThing()
{
     bar<std::string>();
}

Il faut bien �tre conscient que, si tu choisi cette mani�re de travailler, la seule inclusion de mytemplate.h ne suffira pas pour te permettre d'utiliser ce qui est d�clar� dans ce fichier

C'est la raison pour laquelle l'utilisateur final doit carr�ment ignorer l'existence de ce fichier, de mani�re � ne pas �tre tent� de recourir � son contenu

[Davidbrcz]

Un gros +1 koala mais si tu dois vraiment prot�ger le code pour des raisons professionnelles, regarde du cot� de l'[ame="http://fr.wikipedia.org/wiki/Obfuscation"]Obfuscation[/ame] ?

[bacelar]

Je vais faire mon gros lourd sur les exports C++, comme d'hab.

L'utilisation de types template dans les .h d'une dll oblige l'utilisateur de votre librairie � avoir le m�me compilateur et la m�me impl�mentation de le STL que le cr�ateur de la dll.

Une fois encore, je le dis, les exports en C++, c'est de la m****.

En faisant des exports en C, vous n'aurez pas le probl�me car vous devez encapsuler la m�canique interne dans des fonctions. (pas de classe, pas de fonction template)

[koala01]

Un gros +1 koala mais si tu dois vraiment prot�ger le code pour des raisons professionnelles, regarde du cot� de l'Obfuscation ?

A titre personnel, c'est, d�cid�ment, une technique que je refuserai toujours aussi bien de mettre en �uvre que de valider...

D'abord parce que, malgr� tout, elle n'a rien d'infaillible, mais, surtout et principalement parce qu'elle ennuie surtout... celui qui devra maintenir le code...

Bien sur, pour le "commun des mortels", elle peut avoir un effet dissuasif quant � la possibilit� d'�tudier le code, mais, d'un autre cot�, tu pr�pare d�s aujourd'hui la corde qui servira � te pendre dans quelques mois si tu dois revenir dessus

[LittleWhite]

L'Obfuscation ... je suis un peu �tonn�, �a parle pas de ce que je pensais . Un jour j'ai appris que l'on pouvait cach� du code en utiliser des langages �sot�riques. Par exemple, utiliser du brainfuck, ou autre truc � la 'con' pour transformer le code C en un code illisible.
La raison de faire �a, juste parce que nous utilisons OpenOffice ( qui a un par feu, tout le monde le sait ) ou autre logiciel libre, et qu'� certain endroit, malgr� leurs caract�res ouvert, ils doivent cach� le code, car c'est le code qui permet de cripter les mots de passes ( par example ). Du coup �a serait un peu idiot que le code soit visible ( ou les pirates n'auraient plus rien � faire ).
( Pardon de pas avoir dit grand chose d'utile au sujet )

[Davidbrcz]

A titre personnel, c'est, d�cid�ment, une technique que je refuserai toujours aussi bien de mettre en œuvre que de valider...

D'abord parce que, malgr� tout, elle n'a rien d'infaillible, mais, surtout et principalement parce qu'elle ennuie surtout... celui qui devra maintenir le code...

Bien sur, pour le "commun des mortels", elle peut avoir un effet dissuasif quant � la possibilit� d'�tudier le code, mais, d'un autre cot�, tu pr�pare d�s aujourd'hui la corde qui servira � te pendre dans quelques mois si tu dois revenir dessus

Je ne parle pas d'obfuscer le code du d�veloppement (� moins d'�tre SM) mais cr�er une branche clone dans le r�pertoire svn/git qui � chaque mise � jour du code principal se met � jour aussi et s'obfusce automatiquement.Il n'aura plus qu'a distribuer cette branche du projet (il garde ainsi un projet principal propre). Et m�me si ce n'est pas infaillible, ca limite quand m�me pas mal les chances.

[JolyLoic]

Une fois encore, je le dis, les exports en C++, c'est de la m****.

En faisant des exports en C, vous n'aurez pas le probl�me car vous devez encapsuler la m�canique interne dans des fonctions. (pas de classe, pas de fonction template)

Sauf que les exports en C, c'est de la m****.
On ne peut pas utiliser des types qui g�rent bien la m�moire, on ne peut pas exporter une fonction qui va s'adapter au type sur lequel elle est appel�e,... Alors oui, ce qu'on expose est utilisable alors partout, mais un tel nivellement par le bas a un co�t tel que je pr�f�re encore dans de nombreux cas m'en passer.

Et honn�tement, si tu trouves un moyen �l�gant d'exposer en C une fonction comme std::sort, sans perdre les perfs, je suis preneur...


Juste pour info, parce que je ne crois pas que �a ait �t� signal� jusqu'� pr�sent, on peut g�n�ralement ne pas exposer le code des templates si on impose que l'utilisateur du code ne pourra instancier ceux-ci que sur certains types pr�-d�termin�s, et qu'on a fait une instanciation manuelle sur ces types dans la biblioth�que. �a peut �tre utile dans certains cas, mais je suis avant tout persuad� que la protection de code est avant tout une affaire de droit plus qu'une affaire technique.

[salseropom]

Bonjour � tous, merci pour vos r�ponses.

En fait, je d�sire "cacher" le code car je souhaite qu'une personne d�sirant utiliser la librairie n'utilise que les .h (pour avoir la d�claration de la fonction) sans avoir en m�me temps le code de la fonction (template).

Je vais mieux �tudier ce que propose koala01

Sinon, une recherche sur google m'a amen� au mot-cl� "export" (mais qui a certaines limites d'un point de vue compilateur)...

Merci encore

[koala01]

Bonjour � tous, merci pour vos r�ponses.

En fait, je d�sire "cacher" le code car je souhaite qu'une personne d�sirant utiliser la librairie n'utilise que les .h (pour avoir la d�claration de la fonction) sans avoir en m�me temps le code de la fonction (template).

De mani�re g�n�rale, et comme je l'ai fait valoir au d�part, je me demande si cela vaut r�ellement la peine: ton code est-il � ce point "extra-ordinaire" pour que le mal que tu va te donner pour le "cacher" en vaille la peine

De plus, le propre des classes et des fonctions template est, justement, de laisser l'impl�mentation accessible au compilateur, �tant donn� que, typiquement, il ne s'agit que d'impl�mentations d'algorithmes pour lesquelles nous ne connaissons � la base pas les types r�els sur lesquels ils devront �tre appliqu�s.

Je vais mieux �tudier ce que propose koala01

N'oublie pas de prendre la remarque de JolyLoic en compte: une fonction ou une classe template ne peut �tre export�e que s'il existe effectivement une impl�mentation ex�cutable de cette fonction / classe pour un type donn� et d�fini � appliquer.

Et c'est encore plus vrai si tu applique la solution dont je t'ai parl�.

Sinon, une recherche sur google m'a amen� au mot-cl� "export" (mais qui a certaines limites d'un point de vue compilateur)...

il me semble que le mot cl� export n'est, � l'heure actuelle, que tr�s peu support� par les diff�rents compilateurs, ou, du moins, c'�tait le cas la derni�re fois que j'ai crois� une r�f�rence sur le sujet

[yan]

Normalement, tu peut aussi limiter tes templates � groupe pr�d�finie de type. Et ainsi fournir un .lib avec des templates limit�s et en ne donnant que le .h

Code maTemplate.h :

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

1
2
3
4
5
6
 
template<typename T>
struct AA
{
    void ecrire(const T &);
};

Code AA.cpp :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
#include "maTemplate.h"
#include <iostream>
 
template<typename T>
 void AA<T>::ecrire(const T &t)
{
    std::cout<<t<<std::endl;
};
 
//generation du code pour int et char
template AA<int>;
template AA<char>;

Code main.cpp :

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 "maTemplate.h"
 
int main(int argc, char* argv[])
{
    AA<int> a;
    a.ecrire(10);
 
    AA<char> b;
    b.ecrire(10);
 
    AA<double> c;
    c.ecrire(10.5);
    return 0;
}

tu obtiens une erreur de link uniquement pour

Code :

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

1
2
AA<double> c;
 c.ecrire(10.5);

Par contre c'est une erreur de link du coup. Y as peut �tre un moyen pour que ce soit lors du build

[bacelar]

On ne peut pas utiliser des types qui g�rent bien la m�moire, on ne peut pas exporter une fonction qui va s'adapter au type sur lequel elle est appel�e

A moins d'avoir une seule C-runtime dans l'OS, la gestion de la m�moire par les "structures" C++ sont aussi faibles que celles C.
Une fonction qui s'adapte au type mais pas aux options du compilateur, ce n'est pas ce que j'appelle un avantage.

Le nivellement pas le bas ? Il y a un nivellement pas le haut, c'est COM (aussi XCOM sous Linux/FireFox je crois), .NET avec un environnement de typage dans le runtime et pas dans le compilateur et je pense qu'ils en restent bien d'autres (� la rigueur CORBA).