Supprimer "private"

Bertrand Lenoir-Welter wrote:

A mon avis, les notions "public", "private" et "protected" sont surtout
utiles pour créer des librairies publiques ou pour travailler en groupe.
Pour un développeur seul sur un projet, je trouve leur intérêt limité
sinon nul, et j'ai tendance à tout mettre public dans mes classes.

Ceci n'est que mon opinion, hein.

De toute façon, ces définitions ne servent qu'à la compilation et au
link. A l'exécution, il n'y a pas de différence, du moins pas que je sache.

sauf dans l'heritage.

a+, ld.

A mon avis, les notions "public", "private" et "protected" sont surtout
utiles pour créer des librairies publiques ou pour travailler en groupe.
Pour un développeur seul sur un projet, je trouve leur intérêt limité
sinon nul, et j'ai tendance à tout mettre public dans mes classes.

Ceci n'est que mon opinion, hein.

De toute façon, ces définitions ne servent qu'à la compilation et au
link. A l'exécution, il n'y a pas de différence, du moins pas que je sache.

"Bertrand Lenoir-Welter" <bertrand.2004@galaad.net> a écrit dans le message
de news:4327f7d1$0$17219$8fcfb975@news.wanadoo.fr...
| A mon avis, les notions "public", "private" et "protected" sont surtout
| utiles pour créer des librairies publiques ou pour travailler en groupe.
| Pour un développeur seul sur un projet, je trouve leur intérêt limité
| sinon nul, et j'ai tendance à tout mettre public dans mes classes.
|

| Ceci n'est que mon opinion, hein.
|

Je pense que c'est une erreur.
Si ton projet est petit, probablement que cela ne te génera pas.
Mais si ton projet est conséquent ( même si tu es seul à bosser dessus ),
tu as tout intérêt à encapsuler correctement ton code, et là, la
notion de publique/private est très importante.
N'oublie pas que si tu dois te re-plonger dans ton code plusieures semaines,
voir
plusieurs mois après, si ton code n'est pas bien conçu à l'origine tu
t'arracheras les cheveux.

--
-Stan

Fabien LE LEZ <gramster@gramster.com> writes:

Bonjour,

Soit une classe, avec un certain nombre de membres privés ou protégés,
dans un programme donné, terminé, qui fonctionne.

À cause d'un "friend" illégal[*], que gcc n'accepte pas, je souhaite
supprimer la ligne "friend XXX" et les "private:" et "protected:"[**].

Il me semble que cette modification ne changera pas le fonctionnement
du programme.

Quelqu'un pourrait-il confirmer ?

A priori, pour un changement de fonctionnement du programme, tu veux
du code correct avant et apres. Je ne vois que la resolution de
surcharge (en y mettant les conversions implicites) et les templates
pour arriver a cela. Or private et protected ne change que les droits
d'acces, pas la visibilite, ce qui me semble exclure que la resolution
de surcharge puisse changer la semantique.

class C1 {
public:
int f(int);
private:
int f(double);
};

int g1(double d)
{
C1 c;
return c.f(d);
}

n'est pas correct (C::f(double) n'est pas accessible, mais c'est quand
meme la solution choisie par la resolution de surcharge), tandis que

class C2 {
public:
int f(int);
};

int g2(double d)
{
C c;
return c.f(d);
}

l'est (il y a une conversion implicite).

Je ne vois pas de changement de semantique possible dans les cas
simples.

Maintenant si tu joues avec les templates et en particulier le
principe SFINAE, la je ne reponds pas a la question: je ne serais pas
surpris que les techniques de meta-programmation arrive a detecter le
cas et faire des choses differentes avec C1 et C2 (mais je ne connais
pas la methode).

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Bertrand Lenoir-Welter <bertrand.2004@galaad.net> writes:

A mon avis, les notions "public", "private" et "protected" sont surtout
utiles pour créer des librairies publiques ou pour travailler en
groupe. Pour un développeur seul sur un projet, je trouve leur intérêt
limité sinon nul, et j'ai tendance à tout mettre public dans mes classes.

Ceci n'est que mon opinion, hein.

De toute façon, ces définitions ne servent qu'à la compilation et au
link. A l'exécution, il n'y a pas de différence, du moins pas que je sache.

Encapsuler c'est utile pour s'assurer qu'on ne depend pas de chose qui
sont des "details d'implementation". C'est donc en particulier utile
pour celui qui connait bien l'implementation...

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Stan :

Si ton projet est petit, probablement que cela ne te génera pas.

318000 lignes à ce jour. Je sais pas si c'est petit ou gros. Pour moi,
c'est devenu très gros et peut-être même trop gros, mais je fais avec.

Mais si ton projet est conséquent ( même si tu es seul à bosser dessus ),
tu as tout intérêt à encapsuler correctement ton code, et là, la
notion de publique/private est très importante.

Je suis d'accord sans l'être. A mon avis, seule la lisibilité change
quand on bosse seul ou en équipe, et là ça devient moins lié à
l'utilisation de parties publiques ou privées/protégées que de
structuration générale. Un commentaire de 3 mots au bon endroit fait
beaucoup plus qu'une encapsulation orthodoxe.

N'oublie pas que si tu dois te re-plonger dans ton code plusieures semaines,
voir plusieurs mois après, si ton code n'est pas bien conçu à l'origine tu
t'arracheras les cheveux.

Je modifie parfois du code qui date de quelques années en arrière. Quand
c'est écrit avec les pieds, je m'arrache les cheveux. Quand c'est écrit
avec la tête, la méthode d'encapsulation perd toute son importance.


Bon, c'est vrai qu'il vaut mieux coder dans les règles. Mais j'ai aussi
des fonctions dont les droits d'accès changent au fil de la vie du
projet. Sincèrement, le fait de tout mettre en public n'est vraiment pas
mon problème majeur à la relecture.

J'insiste sur le fait que le fait de bosser en équipe change tout.


Mais la question portait sur l'exécution même du code, il me semble. Je
ne pense pas que l'assembleur généré diffère pour une fonction publique
ou privée/protégée.

"Bertrand Lenoir-Welter" <bertrand.2004@galaad.net> a écrit dans le message
de news:43282a85$0$1014$8fcfb975@news.wanadoo.fr...
| Stan :
|
|
| > Si ton projet est petit, probablement que cela ne te génera pas.
|
| 318000 lignes à ce jour. Je sais pas si c'est petit ou gros. Pour moi,
| c'est devenu très gros et peut-être même trop gros, mais je fais avec.
|

Si c'est ce que t'indique ton compilo, ça ne veut rien dire;
si c'est réellement le nombre de lignes que _tu_ as codé, c'est
pas mal.

| > Mais si ton projet est conséquent ( même si tu es seul à bosser
dessus ),
| > tu as tout intérêt à encapsuler correctement ton code, et là, la
| > notion de publique/private est très importante.
|
| Je suis d'accord sans l'être. A mon avis, seule la lisibilité change
| quand on bosse seul ou en équipe, et là ça devient moins lié à
| l'utilisation de parties publiques ou privées/protégées que de
| structuration générale. Un commentaire de 3 mots au bon endroit fait
| beaucoup plus qu'une encapsulation orthodoxe.
|

Résumer la fiabilité d'un source à sa seule lisibilité est une grave erreur.
Des sources très lisibles avec une hiérarchie de classes boiteuse réservera
sans doute des erreurs ( le pire, à l'execution...).

|
| > N'oublie pas que si tu dois te re-plonger dans ton code plusieures
semaines,
| > voir plusieurs mois après, si ton code n'est pas bien conçu à l'origine
tu
| > t'arracheras les cheveux.
|
| Je modifie parfois du code qui date de quelques années en arrière. Quand
| c'est écrit avec les pieds, je m'arrache les cheveux. Quand c'est écrit
| avec la tête, la méthode d'encapsulation perd toute son importance.
|

Je ne connais aucun cas où l'on peut prétende négliger l'encapsulation.

| Bon, c'est vrai qu'il vaut mieux coder dans les règles. Mais j'ai aussi
| des fonctions dont les droits d'accès changent au fil de la vie du
| projet. Sincèrement, le fait de tout mettre en public n'est vraiment pas
| mon problème majeur à la relecture.

Si les droits d'accès changent au cours du projet, c'est sans doute
dû à un problème d'analyse.

| J'insiste sur le fait que le fait de bosser en équipe change tout.
|

Personnellement, j'ai constaté que les méthodes de groupes
avaient un grand intérêt même en solo.
Pense à celui qui reprendra le projet derrière toi...

|
| Mais la question portait sur l'exécution même du code, il me semble. Je
| ne pense pas que l'assembleur généré diffère pour une fonction publique
| ou privée/protégée.

Oui, mais quand on donne son opinion sur quelque chose, il faut
s'attendre à des réactions ;-)


--
-Stan

Stan :

Si c'est ce que t'indique ton compilo, ça ne veut rien dire;

Certes, je suis pas bête à ce point. Lui m'affiche plusieurs millions.

si c'est réellement le nombre de lignes que _tu_ as codé, c'est
pas mal.

Je me suis fait un petit outil pour satisfaire ma curiosité, outil qui
élimine les commentaires et les lignes qui ne contiennent pas au moins
un point-virgule ou une virgule (pour les déclarations de variables).
Donc 318000 et quelques lignes de code perso et actif.

Résumer la fiabilité d'un source à sa seule lisibilité est une grave erreur.

Mais j'ai pas dit ça.

Je ne connais aucun cas où l'on peut prétende négliger l'encapsulation.

J'ai pas dit ça non plus. Seulement que la répartition public/private
n'a de sens qu'à la compilation et plus aucun à l'exécution, et que son
intérêt faiblit beaucoup dans le cas d'un projet où l'on bosse seul. Je
n'ai pas extrapolé.

Si les droits d'accès changent au cours du projet, c'est sans doute
dû à un problème d'analyse.

Certes. Mais quand vous avez un projet avec 318000 lignes de code qui
évolue depuis 6 ans, vous accordez plus facilement quelques
circonstances atténuantes à votre propre analyse lointainement passée.

En théorie statique, on a un projet bouclé, bien analysé, bien codé,
bien encapsulé. En pratique dynamique, ça devient un peu plus flou...

Si je regarde mon analyse d'il y a 6 ans au vu du projet aujourd'hui,
c'est pas bon sur plusieurs points. Si je regarde mon analyse au vu du
projet de l'époque, ça devient acceptable. Mais les projets évoluent
avec les demandes des utilisateurs, lesquelles sont la plupart du temps
imprévisibles. Je suis pas Madame Irma.

Bon, on est sorti de la route, là.

Personnellement, j'ai constaté que les méthodes de groupes
avaient un grand intérêt même en solo.

J'ai pas dit le contraire non plus. Mais on a chacun ses manies et ses
tics. Personnellement, je mets tout en public et ça m'a jamais causé de
souci. Je milite pas pour ça, hein, pas de quiproquo... Chacun fait ce
qu'il veut sauf s'il travaille en équipe. Mais c'est pas mon cas.

Pense à celui qui reprendra le projet derrière toi...

Personne. Mais je persiste à penser qu'un bon commentaire fait gagner
plus de temps qu'une répartition public/private dans les formes.

Oui, mais quand on donne son opinion sur quelque chose, il faut
s'attendre à des réactions ;-)

Tout à fait. Mon opinion est qu'un projet solo bien ficelé est un projet
1- qui fonctionne et 2- qu'on arrive à maintenir. Après, chacun voit
midi à sa porte sur la façon d'y arriver. Je préfère un code astucieux
et mal écrit qu'un code orthodoxe qui déconne. Oui, oui, vous préférez
un code astucieux et orthodoxe. Mais sur un gros projet solo et
évolutif, vous comprenez bien qu'on fait au mieux avec ce qu'on sait
faire dans l'instant, pourvu que ça fonctionne bien.

J'ajoute que le fait d'avoir un code pas toujours clairement lisible m'a
plusieurs fois permis de l'améliorer a posteriori en cherchant à
comprendre ce que j'avais écrit quelques années plus tôt. Vu avec un
oeil neuf, c'est parfois magiques les idées nouvelles qu'on peut y
appliquer. Moins évident quand la lecture est très implicite. Bon, je
vais me faire incendier. Pourtant, c'est ce que j'ai constaté.

On Wed, 14 Sep 2005 17:02:39 +0200, Bertrand Lenoir-Welter
<bertrand.2004@galaad.net>:

J'ai pas dit ça non plus. Seulement que la répartition public/private
n'a de sens qu'à la compilation et plus aucun à l'exécution, et que son
intérêt faiblit beaucoup dans le cas d'un projet où l'on bosse seul.

Si tu arrives à te rappeler toutes les idiosyncrasies de toutes tes
classes, des mois ou des années après, je te félicite. Moi, après
trois jours, j'ai déjà du mal.



Un petit exemple :

template <class T> class Faillible
{
public:
...
T GetValeur() const
{
assert (Ok());
return valeur;
}
bool Ok() const { return ok; }

private:
T valeur;
bool ok;
};

On ne doit jamais lire le contenu de "valeur" si "ok" est à "false".
(Si "T" est un pointeur, la ligne "return valeur;" génère un
comportement indéfini.)

Sans "private:", tu dois le vérifier, à chaque fois que tu utilises
cette classe, que tu modifies (directement ou indirectement) le code
qui l'utilise, etc.

Avec "private:", le compilateur le fait pour toi -- il n'y a pas moyen
d'utiliser cette classe de manière incorrecte sans générer une erreur.

Stan :

Si tu utilises une hierarchie de classes ou tout est public,
tu as le risque d'avoir des gros pb à l'execution et ce sans
la moindre erreur de compilation.

Un exemple ?