[**] Oui, je sais, ce n'est pas forcément une idée géniale, mais comme
je ne compte pas pondre du code qui utilise directement ces classes,
je ne pense pas avoir besoin de la protection apportée par "private"
et "protected".
"Bertrand Lenoir-Welter" a écrit dans le message de news:43283b88$0$986$ | | 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
Non. 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.
Evidemment, tu as toujours le recours de mettre 3 lignes de commentaire au dessus de chaque méthode pour décrire la manière dont elle est censé être utilisé; mais je pense que le compilateur est plus performant pour détecter les anomalies.
-- -Stan
"Bertrand Lenoir-Welter" <bertrand.2004@galaad.net> a écrit dans le message
de news:43283b88$0$986$8fcfb975@news.wanadoo.fr...
|
| 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
Non.
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.
Evidemment, tu as toujours le recours de mettre 3 lignes
de commentaire au dessus de chaque méthode pour
décrire la manière dont elle est censé être utilisé;
mais je pense que le compilateur est plus
performant pour détecter les anomalies.
"Bertrand Lenoir-Welter" a écrit dans le message de news:43283b88$0$986$ | | 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
Non. 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.
Evidemment, tu as toujours le recours de mettre 3 lignes de commentaire au dessus de chaque méthode pour décrire la manière dont elle est censé être utilisé; mais je pense que le compilateur est plus performant pour détecter les anomalies.
-- -Stan
Bertrand Lenoir-Welter
Fabien LE LEZ :
T GetValeur() const { assert (Ok()); return valeur; }
Fabien, trouve un exemple où ce genre de code a un sens sérieux et incontournable. Personnellement, j'écrirai jamais un truc comme ça.
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.
T'es en train de me dire qu'un private te permet de ne pas te conduire comme un abruti total. Certes, mais c'est très limité et ça ne t'empêchera pas de commettre tes conneries plus loin. On est entre gens sérieux, non ?
Fabien LE LEZ :
T GetValeur() const
{
assert (Ok());
return valeur;
}
Fabien, trouve un exemple où ce genre de code a un sens sérieux et
incontournable. Personnellement, j'écrirai jamais un truc comme ça.
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.
T'es en train de me dire qu'un private te permet de ne pas te conduire
comme un abruti total. Certes, mais c'est très limité et ça ne
t'empêchera pas de commettre tes conneries plus loin. On est entre gens
sérieux, non ?
T GetValeur() const { assert (Ok()); return valeur; }
Fabien, trouve un exemple où ce genre de code a un sens sérieux et incontournable. Personnellement, j'écrirai jamais un truc comme ça.
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.
T'es en train de me dire qu'un private te permet de ne pas te conduire comme un abruti total. Certes, mais c'est très limité et ça ne t'empêchera pas de commettre tes conneries plus loin. On est entre gens sérieux, non ?
Fabien LE LEZ
On Wed, 14 Sep 2005 18:14:49 +0200, Bertrand Lenoir-Welter :
Fabien, trouve un exemple où ce genre de code a un sens sérieux et incontournable.
<news: <news:430c2560$0$18591$
On Wed, 14 Sep 2005 18:14:49 +0200, Bertrand Lenoir-Welter
<bertrand.2004@galaad.net>:
Fabien, trouve un exemple où ce genre de code a un sens sérieux et
incontournable.
On Wed, 14 Sep 2005 18:14:49 +0200, Bertrand Lenoir-Welter :
T'es en train de me dire qu'un private te permet de ne pas te conduire comme un abruti total.
J'avais des doutes sur le caractère trollatif de ton intervention ; ils sont levés...
Jean-Marc Bourguet
Fabien LE LEZ writes:
J'avais des doutes sur le caractère trollatif de ton intervention ; ils sont levés...
Pour les trolls restez sur fr.comp.algorithmes SVP.
Merci.
-- 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
Fabien LE LEZ <gramster@gramster.com> writes:
J'avais des doutes sur le caractère trollatif de ton intervention ;
ils sont levés...
Pour les trolls restez sur fr.comp.algorithmes SVP.
Merci.
--
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
J'avais des doutes sur le caractère trollatif de ton intervention ; ils sont levés...
Pour les trolls restez sur fr.comp.algorithmes SVP.
Merci.
-- 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
Fabien LE LEZ :
J'avais des doutes sur le caractère trollatif de ton intervention ; ils sont levés...
Avis d'orfèvre ?
Fabien LE LEZ :
J'avais des doutes sur le caractère trollatif de ton intervention ;
ils sont levés...
J'avais des doutes sur le caractère trollatif de ton intervention ; ils sont levés...
Avis d'orfèvre ?
kanze
Fabien LE LEZ wrote:
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 ?
C'est au moins l'intention -- si un programme compile et fonctionne correctement, supprimer tous les contrôles d'accès en rendant tout public ne doit rien changer. (Note bien, par exemple, que le « name binding » et la résolution du surcharge ont lieu sans prendre en compte les contrôles d'accès. Je crois que c'est pareil pour tout ce qui concerne les templates, mais je m'y connais moins bien.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
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 ?
C'est au moins l'intention -- si un programme compile et
fonctionne correctement, supprimer tous les contrôles d'accès en
rendant tout public ne doit rien changer. (Note bien, par
exemple, que le « name binding » et la résolution du surcharge
ont lieu sans prendre en compte les contrôles d'accès. Je crois
que c'est pareil pour tout ce qui concerne les templates, mais
je m'y connais moins bien.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
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 ?
C'est au moins l'intention -- si un programme compile et fonctionne correctement, supprimer tous les contrôles d'accès en rendant tout public ne doit rien changer. (Note bien, par exemple, que le « name binding » et la résolution du surcharge ont lieu sans prendre en compte les contrôles d'accès. Je crois que c'est pareil pour tout ce qui concerne les templates, mais je m'y connais moins bien.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Bertrand Lenoir-Welter wrote:
Fabien LE LEZ :
T GetValeur() const { assert (Ok()); return valeur; }
Fabien, trouve un exemple où ce genre de code a un sens sérieux et incontournable.
C'est un idiome (on dirait aujourd'hui un modèle de conception) standard et répandu. Je crois que je n'ai jamais écrit une application sans me servir de Fallible quelque part -- il sert donc dans les noeuds principaux du reseau Deutsch Telekom, dans des logiciels d'allocation des IP WAP pour T Mobil, dans la gestion des ordres en Bourse...
Personnellement, j'écrirai jamais un truc comme ça.
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.
T'es en train de me dire qu'un private te permet de ne pas te conduire comme un abruti total.
Il s'assure que tu ne fasses pas un type de bêtise. Il y a toujours ça de gagner.
Certes, mais c'est très limité et ça ne t'empêchera pas de commettre tes conneries plus loin.
Il n'y a pas de « silver bullet ». Mais des bêtises sont si vite faites, il faut mettre tout de notre côté qu'on peut.
Réalistiquement, j'ai une expérience de plus de trente ans. Avant de faire du C++, je faisais du C. J'écrivais des struct, et une série de fonctions pour les manipuler, et je me croisais les doigts que personne ne les manipule autrement que par mes fonctions. Avec private, c'est le compilateur qui s'en occupe. C'était, et ça reste, l'innovation la plus importante du C++ par rapport au C.
Évidemment, il reste beaucoup d'autres bêtises à faire. Mais il y a toujours ça de gagner.
On est entre gens sérieux, non ?
Je me le démande.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Bertrand Lenoir-Welter wrote:
Fabien LE LEZ :
T GetValeur() const
{
assert (Ok());
return valeur;
}
Fabien, trouve un exemple où ce genre de code a un sens sérieux et
incontournable.
C'est un idiome (on dirait aujourd'hui un modèle de conception)
standard et répandu. Je crois que je n'ai jamais écrit une
application sans me servir de Fallible quelque part -- il sert
donc dans les noeuds principaux du reseau Deutsch Telekom, dans
des logiciels d'allocation des IP WAP pour T Mobil, dans la
gestion des ordres en Bourse...
Personnellement, j'écrirai jamais un truc comme ça.
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.
T'es en train de me dire qu'un private te permet de ne pas te
conduire comme un abruti total.
Il s'assure que tu ne fasses pas un type de bêtise. Il y a
toujours ça de gagner.
Certes, mais c'est très limité et ça ne t'empêchera pas de
commettre tes conneries plus loin.
Il n'y a pas de « silver bullet ». Mais des bêtises sont si vite
faites, il faut mettre tout de notre côté qu'on peut.
Réalistiquement, j'ai une expérience de plus de trente ans.
Avant de faire du C++, je faisais du C. J'écrivais des struct,
et une série de fonctions pour les manipuler, et je me croisais
les doigts que personne ne les manipule autrement que par mes
fonctions. Avec private, c'est le compilateur qui s'en occupe.
C'était, et ça reste, l'innovation la plus importante du C++ par
rapport au C.
Évidemment, il reste beaucoup d'autres bêtises à faire. Mais il
y a toujours ça de gagner.
On est entre gens sérieux, non ?
Je me le démande.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
T GetValeur() const { assert (Ok()); return valeur; }
Fabien, trouve un exemple où ce genre de code a un sens sérieux et incontournable.
C'est un idiome (on dirait aujourd'hui un modèle de conception) standard et répandu. Je crois que je n'ai jamais écrit une application sans me servir de Fallible quelque part -- il sert donc dans les noeuds principaux du reseau Deutsch Telekom, dans des logiciels d'allocation des IP WAP pour T Mobil, dans la gestion des ordres en Bourse...
Personnellement, j'écrirai jamais un truc comme ça.
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.
T'es en train de me dire qu'un private te permet de ne pas te conduire comme un abruti total.
Il s'assure que tu ne fasses pas un type de bêtise. Il y a toujours ça de gagner.
Certes, mais c'est très limité et ça ne t'empêchera pas de commettre tes conneries plus loin.
Il n'y a pas de « silver bullet ». Mais des bêtises sont si vite faites, il faut mettre tout de notre côté qu'on peut.
Réalistiquement, j'ai une expérience de plus de trente ans. Avant de faire du C++, je faisais du C. J'écrivais des struct, et une série de fonctions pour les manipuler, et je me croisais les doigts que personne ne les manipule autrement que par mes fonctions. Avec private, c'est le compilateur qui s'en occupe. C'était, et ça reste, l'innovation la plus importante du C++ par rapport au C.
Évidemment, il reste beaucoup d'autres bêtises à faire. Mais il y a toujours ça de gagner.
On est entre gens sérieux, non ?
Je me le démande.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Laurent Deniau wrote:
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.
Même là, je crois. Les contrôles d'accès disparaissent après la compilation, systèmatiquement. Les contrôles d'accès ne s'appliquent qu'en dernier lieu par le compilateur, après le « name binding » et la résolution du surcharge. Ils peuvent rendre un programme illégal qui serait autrement légal, mais je crois que leur effet s'arrêt là. Surtout, si un programme est légal, et a une sémantique bien définie, je crois que rendre tout public ne change rien.
Mais je me démande si tu ne faisais pas référence au dynamic_cast -- un dynamic_cast respecte, en effet, les private, et il se fait à l'exécution. Moi, je sais qu'en fait, il travaille à partir des tables construites par le compilateur, et que donc, la prise en compte des contrôles d'accès a lieu uniquement dans le compilateur, lors de la construction de ces tables. Mais c'est une particularité de l'implémentation, et je conçois bien qu'un utilisateur moyen le considère comme un prise en compte des contrôles d'accès lors de l'exécution.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Laurent Deniau wrote:
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.
Même là, je crois. Les contrôles d'accès disparaissent après la
compilation, systèmatiquement. Les contrôles d'accès ne
s'appliquent qu'en dernier lieu par le compilateur, après le
« name binding » et la résolution du surcharge. Ils peuvent
rendre un programme illégal qui serait autrement légal, mais je
crois que leur effet s'arrêt là. Surtout, si un programme est
légal, et a une sémantique bien définie, je crois que rendre
tout public ne change rien.
Mais je me démande si tu ne faisais pas référence au
dynamic_cast -- un dynamic_cast respecte, en effet, les private,
et il se fait à l'exécution. Moi, je sais qu'en fait, il
travaille à partir des tables construites par le compilateur, et
que donc, la prise en compte des contrôles d'accès a lieu
uniquement dans le compilateur, lors de la construction de ces
tables. Mais c'est une particularité de l'implémentation, et je
conçois bien qu'un utilisateur moyen le considère comme un prise
en compte des contrôles d'accès lors de l'exécution.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
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.
Même là, je crois. Les contrôles d'accès disparaissent après la compilation, systèmatiquement. Les contrôles d'accès ne s'appliquent qu'en dernier lieu par le compilateur, après le « name binding » et la résolution du surcharge. Ils peuvent rendre un programme illégal qui serait autrement légal, mais je crois que leur effet s'arrêt là. Surtout, si un programme est légal, et a une sémantique bien définie, je crois que rendre tout public ne change rien.
Mais je me démande si tu ne faisais pas référence au dynamic_cast -- un dynamic_cast respecte, en effet, les private, et il se fait à l'exécution. Moi, je sais qu'en fait, il travaille à partir des tables construites par le compilateur, et que donc, la prise en compte des contrôles d'accès a lieu uniquement dans le compilateur, lors de la construction de ces tables. Mais c'est une particularité de l'implémentation, et je conçois bien qu'un utilisateur moyen le considère comme un prise en compte des contrôles d'accès lors de l'exécution.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Laurent Deniau
kanze wrote:
Laurent Deniau wrote:
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.
Mais je me démande si tu ne faisais pas référence au dynamic_cast -- un dynamic_cast respecte, en effet, les private, et il se fait à l'exécution. Moi, je sais qu'en fait, il
C'est a ca que je faisais reference et c'etait pour indiquer que dans le cas de l'heritage, le comportement d'un programme peut changer si on enleve/ajoute private.
a+, ld.
kanze wrote:
Laurent Deniau wrote:
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.
Mais je me démande si tu ne faisais pas référence au
dynamic_cast -- un dynamic_cast respecte, en effet, les private,
et il se fait à l'exécution. Moi, je sais qu'en fait, il
C'est a ca que je faisais reference et c'etait pour indiquer que dans le
cas de l'heritage, le comportement d'un programme peut changer si on
enleve/ajoute private.
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.
Mais je me démande si tu ne faisais pas référence au dynamic_cast -- un dynamic_cast respecte, en effet, les private, et il se fait à l'exécution. Moi, je sais qu'en fait, il
C'est a ca que je faisais reference et c'etait pour indiquer que dans le cas de l'heritage, le comportement d'un programme peut changer si on enleve/ajoute private.
