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).