[c++] Question sur les .lib

Question sur les .lib [c++] - C++ - Programmation

Marsh Posté le 04-08-2003 à 22:27:14    

Salut,
 
Voila j'ai fait une librairie statique (.lib) de mon code en C++ pour le donner a quelqu'un qui va l'integrer dans un projet.  
Le probleme c'est que je dois aussi fournir les .h qui vont bien et c'est la que ca me gene: si je file les .h de mes classes, la personne aura acces a tous les champs et methodes publiques de mes classes et pas seulement celle que je veux qu'elle utilise. Du coup, je peux pas garantir une securité suffisante dans l'utilisation de mon code.
Si en C++, il y avait la notion de package comme en Java ca serait l'ideal, je mettrais tout ce que je veux garder pour moi en protected. Mais, en C++, protected ne donne acces qu'a une classe qui herite (je me trompe ?)....
 
Comment je pourrais wrapper mes classes (ou mes .h) pour ne faire apparaitre que ce que le gars peux utiliser ?


Message édité par fykman le 04-08-2003 à 22:29:56
Reply

Marsh Posté le 04-08-2003 à 22:27:14   

Reply

Marsh Posté le 04-08-2003 à 22:50:21    

Le mécanisme des membres protected/private n'a jamais été imaginé pour cacher tes chefs d'ouvres programmatiques.
 
Pour cela, passe plutot par une classe dummy qui fait l'interface des tes librairies et dont tu passes le header aux clients, ce qui a pour but de "cacher" ( :sarcastic: ) les classes contenant les suscités chefs d'oeuvres de programmation.

Reply

Marsh Posté le 04-08-2003 à 22:59:23    

SchnapsMann a écrit :

Le mécanisme des membres protected/private n'a jamais été imaginé pour cacher tes chefs d'ouvres programmatiques.
 
Pour cela, passe plutot par une classe dummy qui fait l'interface des tes librairies et dont tu passes le header aux clients, ce qui a pour but de "cacher" ( :sarcastic: ) les classes contenant les suscités chefs d'oeuvres de programmation.


 
Hehe, on se calme ....
quand je parle de securité, je veux pas parler me faire piquer le code hein, c'est juste que si la personne modifie les champs ou appelle des methodes n'importe comment, et dans n'importe quel ordre, je peux pas garantir que le code va pas se planter lamantablement, c tout... donc j'aimerais cachér certaines methodes et les certain membres
 
Pfff, ya une putain d'atmosphere sur ce forum, ca empire de jour en jour ...  :pfff:


Message édité par fykman le 04-08-2003 à 23:02:13
Reply

Marsh Posté le 04-08-2003 à 23:05:51    

fykman a écrit :


 
Hehe, on se calme ....
quand je parle de securité, je veux pas parler me faire piquer le code hein, c'est juste que si la personne modifie les champs ou appelle des methodes n'importe comment, et dans n'importe quel ordre, je peux pas garantir que le code va pas se planter lamantablement, c tout... donc j'aimerais cachér certaines methodes et les certain membres
 
Pfff, ya une putain d'atmosphere sur ce forum, ca empire de jour en jour ...  :pfff:


 
et bien dans ce cas, limite les membres public pour l'interface extérieure de ta classe.
 
Pour le reste, utilise protected/private et friend pour les accès entre tes propres classes.
 
"Cacher des méthodes", ce n'est pas possible.

Reply

Marsh Posté le 04-08-2003 à 23:12:18    

Il me semblait avoir entendu que friend etait a proscrire mais je sais plus pour quelle raison...  
Je dois surement me tromper... [:spamafote]

Reply

Marsh Posté le 04-08-2003 à 23:14:39    

et s'il compile avec un "bon" .h est qu'il donne un .h en partie coupé, ça devrait passer non ?
 
les méthode ne son pas incluses dans les données d'une structure, donc d'une classe.
 
une classe définie avec moins de méthodes reste compatible ?
 
ex :
 
je compile avec :
 

Code :
  1. maClasse::methodePublique();
  2. maClasse::methodePrivée();


 
et je fournis :
 

Code :
  1. maClasse::methodePublique();


 
seulement.


---------------
Envie de backuper un DVD en DivX mais vous y connaissez rien ? essayez dvd-ripp : le site de Maxime
Reply

Marsh Posté le 04-08-2003 à 23:14:58    

fykman a écrit :

Il me semblait avoir entendu que friend etait a proscrire mais je sais plus pour quelle raison...  
Je dois surement me tromper... [:spamafote]


 
http://www.parashift.com/c++-faq-l [...] l#faq-14.2
 

Citation :


Do friends violate encapsulation?
No! If they're used properly, they enhance encapsulation.  
 
You often need to split a class in half when the two halves will have different numbers of instances or different lifetimes. In these cases, the two halves usually need direct access to each other (the two halves used to be in the same class, so you haven't increased the amount of code that needs direct access to a data structure; you've simply reshuffled the code into two classes instead of one). The safest way to implement this is to make the two halves friends of each other.  
 
If you use friends like just described, you'll keep private things private. People who don't understand this often make naive efforts to avoid using friendship in situations like the above, and often they actually destroy encapsulation. They either use public data (grotesque!), or they make the data accessible between the halves via public get() and set() member functions. Having a public get() and set() member function for a private datum is OK only when the private datum "makes sense" from outside the class (from a user's perspective). In many cases, these get()/set() member functions are almost as bad as public data: they hide (only) the name of the private datum, but they don't hide the existence of the private datum.  
 
Similarly, if you use friend functions as a syntactic variant of a class's public access functions, they don't violate encapsulation any more than a member function violates encapsulation. In other words, a class's friends don't violate the encapsulation barrier: along with the class's member functions, they are the encapsulation barrier.  
 
(Many people think of a friend function as something outside the class. Instead, try thinking of a friend function as part of the class's public interface. A friend function in the class declaration doesn't violate encapsulation any more than a public member function violates encapsulation: both have exactly the same authority with respect to accessing the class's non-public parts.)  


Message édité par schnapsmann le 04-08-2003 à 23:16:16
Reply

Marsh Posté le 05-08-2003 à 03:43:34    

fykman a écrit :


 
Hehe, on se calme ....
quand je parle de securité, je veux pas parler me faire piquer le code hein, c'est juste que si la personne modifie les champs ou appelle des methodes n'importe comment, et dans n'importe quel ordre, je peux pas garantir que le code va pas se planter lamantablement, c tout... donc j'aimerais cachér certaines methodes et les certain membres
 
Pfff, ya une putain d'atmosphere sur ce forum, ca empire de jour en jour ...  :pfff:


 
Normalement, tous ce qui est en private ou pretected est sencé n'être utilisé que dans la class même.
 
Si maintenant, la personne modifie ton header pour utiliser certaines fonctions pretected en plublic et que ca merde, c'est son problème.
 
Sinon, comme pour SchnapsMann ca me gêne un peu ce genre de méthode dans le sens où je suis pour l'open source.

Reply

Marsh Posté le 05-08-2003 à 08:56:39    

fykman a écrit :


 
Hehe, on se calme ....
quand je parle de securité, je veux pas parler me faire piquer le code hein, c'est juste que si la personne modifie les champs ou appelle des methodes n'importe comment, et dans n'importe quel ordre, je peux pas garantir que le code va pas se planter lamantablement, c tout... donc j'aimerais cachér certaines methodes et les certain membres
 
Pfff, ya une putain d'atmosphere sur ce forum, ca empire de jour en jour ...  :pfff:


 
Si t'as ce genre de problèmes c que tes classes sont male conçues. Tu devrais reprendre ton code pour voir si tu peux pas améliorer les choses.


---------------
Le Tyran
Reply

Marsh Posté le 11-08-2003 à 02:16:01    

<<Comment je pourrais wrapper mes classes (ou mes .h) pour ne faire apparaitre que ce que le gars peux utiliser?>>
 
Crée une surclasse juste pour l'interface (cf. design patterns).

Reply

Marsh Posté le 11-08-2003 à 02:16:01   

Reply

Marsh Posté le 11-08-2003 à 07:04:02    

dans Tinking in C++ Volume 2, y a une section consacrée au CheshireCat. c'est la seule technique valable.
 
http://www.gnu.org/home.fr.html

Reply

Marsh Posté le 11-08-2003 à 12:09:42    

Taz a écrit :

c'est la seule technique valable


 
Pourquoi ne pas utiliser une classe abstraite qui jouerait le role d'interface, dont la "vraie" classe serait dérivée? Le code client ne connaissant que la classe abstraite et une fonction de création de l'objet.

Reply

Marsh Posté le 11-08-2003 à 12:24:23    

oui ça marche, mais tu dois tout passer par allocation dynamique... et tout passer par l'appel de fonction, i.e une fabrique

Reply

Marsh Posté le 11-08-2003 à 13:49:11    

Pour la description de la technique Cheshire Cat
http://www.octopull.demon.co.uk/arglib/TheGrin.html
les autres techniques sont détaillées sur le meme site, en cherchant un peu.

Reply

Marsh Posté le 11-08-2003 à 13:52:53    

qui fonctionne par ce que le compilateur sait tres bien quelle taille allouer pour un "implementation*". c'est là l'astuce.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed