C++

[c++] Question sur les .lib

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : [c++] Question sur les .lib

fykman

Errare Humanum Est

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

Publicité

schnapsmann

Zaford Beeblefect

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.

fykman

Errare Humanum Est

SchnapsMann 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:

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

schnapsmann

Zaford Beeblefect

fykman a écrit :

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.

fykman

Errare Humanum Est

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

jesus_christ

votre nouveau dieu

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 :

maClasse::methodePublique();
maClasse::methodePrivée();

et je fournis :

Code :

maClasse::methodePublique();

seulement.

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

schnapsmann

Zaford Beeblefect

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

iS@mi

Resistance is futile !

fykman a écrit :

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.

LetoII

Le dormeur doit se réveiller

fykman a écrit :

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

ACut

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

Publicité

Taz

bisounours-codeur

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

Ace17

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.

Taz

bisounours-codeur

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

Ace17

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.

Taz

bisounours-codeur

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

FORUM HardWare.fr

Programmation

C++

[c++] Question sur les .lib

Sujets relatifs
[PHP] Question sur les Header	[python]Question de saut de ligne
SQL question à la con : i++	[PHP] Session, question sur le passage de l'ID par URL
[makefile] question pointues	Question methode c++ (algo)
Swing: une chtite question sur le redimentionnement	[HTML] Question sur TABLE
question concernant VBA et methode saveAs	Question simple JS....
Plus de sujets relatifs à : [c++] Question sur les .lib

Page générée en 0.070 secondes