Just un détail du langage, mais tu te contradis là. Justement, en C++ les contrôles d'accès (public, private) ne concerne pas la visibilité -- un symbole est *visible* qu'il soit privé ou non. Le compilateur fait tout ce qu'il doit faire : name binding, résolution du surcharge, etc., sans prendre l'accès en considération. Seulement, si après tout ça, il s'avère que tu as essayé d'utiliser un symbole dont tu n'as pas le droit, tu as une erreur.
Oui, mais ça, c'est l'implémentation. Le terme de visibilité permet d'imager ce comportement. Il me semble qu'il n'apporte auncune contradiction avec le comportement d'ordre supérieur. Me trompe-je ?
-- "Yo!" Martin Heidegger
Just un détail du langage, mais tu te contradis là. Justement,
en C++ les contrôles d'accès (public, private) ne concerne pas
la visibilité -- un symbole est *visible* qu'il soit privé ou
non. Le compilateur fait tout ce qu'il doit faire : name
binding, résolution du surcharge, etc., sans prendre l'accès en
considération. Seulement, si après tout ça, il s'avère que tu as
essayé d'utiliser un symbole dont tu n'as pas le droit, tu as
une erreur.
Oui, mais ça, c'est l'implémentation. Le terme de visibilité permet
d'imager ce comportement. Il me semble qu'il n'apporte auncune
contradiction avec le comportement d'ordre supérieur. Me trompe-je ?
Just un détail du langage, mais tu te contradis là. Justement, en C++ les contrôles d'accès (public, private) ne concerne pas la visibilité -- un symbole est *visible* qu'il soit privé ou non. Le compilateur fait tout ce qu'il doit faire : name binding, résolution du surcharge, etc., sans prendre l'accès en considération. Seulement, si après tout ça, il s'avère que tu as essayé d'utiliser un symbole dont tu n'as pas le droit, tu as une erreur.
Oui, mais ça, c'est l'implémentation. Le terme de visibilité permet d'imager ce comportement. Il me semble qu'il n'apporte auncune contradiction avec le comportement d'ordre supérieur. Me trompe-je ?
-- "Yo!" Martin Heidegger
Jean-Marc Bourguet
Yoxoman writes:
Just un détail du langage, mais tu te contradis là. Justement, en C++ les contrôles d'accès (public, private) ne concerne pas la visibilité -- un symbole est *visible* qu'il soit privé ou non. Le compilateur fait tout ce qu'il doit faire : name binding, résolution du surcharge, etc., sans prendre l'accès en considération. Seulement, si après tout ça, il s'avère que tu as essayé d'utiliser un symbole dont tu n'as pas le droit, tu as une erreur.
Oui, mais ça, c'est l'implémentation. Le terme de visibilité permet d'imager ce comportement.
J'ai l'impression que tu oublies que le terme "visibilite" est un terme technique quand on parle de C++, qui dont a une definition precise.
Si tu te mets a melanger sa definition tel le que deduite de la norme et une autre qui correspond a ce que tu veux expliquer, il ne faut pas s'etonner si on te contredit ou ne te comprends pas.
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
Yoxoman <yoxoman@aol.com> writes:
Just un détail du langage, mais tu te contradis là. Justement,
en C++ les contrôles d'accès (public, private) ne concerne pas
la visibilité -- un symbole est *visible* qu'il soit privé ou
non. Le compilateur fait tout ce qu'il doit faire : name
binding, résolution du surcharge, etc., sans prendre l'accès en
considération. Seulement, si après tout ça, il s'avère que tu as
essayé d'utiliser un symbole dont tu n'as pas le droit, tu as
une erreur.
Oui, mais ça, c'est l'implémentation. Le terme de visibilité permet
d'imager ce comportement.
J'ai l'impression que tu oublies que le terme "visibilite" est un
terme technique quand on parle de C++, qui dont a une definition
precise.
Si tu te mets a melanger sa definition tel le que deduite de la norme
et une autre qui correspond a ce que tu veux expliquer, il ne faut pas
s'etonner si on te contredit ou ne te comprends pas.
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
Just un détail du langage, mais tu te contradis là. Justement, en C++ les contrôles d'accès (public, private) ne concerne pas la visibilité -- un symbole est *visible* qu'il soit privé ou non. Le compilateur fait tout ce qu'il doit faire : name binding, résolution du surcharge, etc., sans prendre l'accès en considération. Seulement, si après tout ça, il s'avère que tu as essayé d'utiliser un symbole dont tu n'as pas le droit, tu as une erreur.
Oui, mais ça, c'est l'implémentation. Le terme de visibilité permet d'imager ce comportement.
J'ai l'impression que tu oublies que le terme "visibilite" est un terme technique quand on parle de C++, qui dont a une definition precise.
Si tu te mets a melanger sa definition tel le que deduite de la norme et une autre qui correspond a ce que tu veux expliquer, il ne faut pas s'etonner si on te contredit ou ne te comprends pas.
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
Yoxoman
J'ai l'impression que tu oublies que le terme "visibilite" est un terme technique quand on parle de C++, qui dont a une definition precise.
Bah oui. En tapant "visibilité poo" sous google, le premier lien est :
http://www.commentcamarche.net/poo/encapsul.php3
qui correspond plutôt à ce que je déclare, et que James Kanze me contredis. Je discute. C'est tout.
Si tu te mets a melanger sa definition tel le que deduite de la norme
Je n'ai (bien entendu) pas la norme. De plus, je doute que la norme d'un terme correponde au terme de cette norme.
et une autre qui correspond a ce que tu veux expliquer, il ne faut pas s'etonner si on te contredit ou ne te comprends pas.
Je ne m'étonne pas. Je discute.
-- "Yo!" Martin Heidegger
J'ai l'impression que tu oublies que le terme "visibilite" est un
terme technique quand on parle de C++, qui dont a une definition
precise.
Bah oui. En tapant "visibilité poo" sous google, le premier lien est :
http://www.commentcamarche.net/poo/encapsul.php3
qui correspond plutôt à ce que je déclare, et que James Kanze me
contredis. Je discute. C'est tout.
Si tu te mets a melanger sa definition tel le que deduite de la norme
Je n'ai (bien entendu) pas la norme. De plus, je doute que la norme d'un
terme correponde au terme de cette norme.
et une autre qui correspond a ce que tu veux expliquer, il ne faut pas
s'etonner si on te contredit ou ne te comprends pas.
J'ai l'impression que tu oublies que le terme "visibilite" est un terme technique quand on parle de C++, qui dont a une definition precise.
Bah oui. En tapant "visibilité poo" sous google, le premier lien est :
http://www.commentcamarche.net/poo/encapsul.php3
qui correspond plutôt à ce que je déclare, et que James Kanze me contredis. Je discute. C'est tout.
Si tu te mets a melanger sa definition tel le que deduite de la norme
Je n'ai (bien entendu) pas la norme. De plus, je doute que la norme d'un terme correponde au terme de cette norme.
et une autre qui correspond a ce que tu veux expliquer, il ne faut pas s'etonner si on te contredit ou ne te comprends pas.
Je ne m'étonne pas. Je discute.
-- "Yo!" Martin Heidegger
Jean-Marc Bourguet
Yoxoman writes:
J'ai l'impression que tu oublies que le terme "visibilite" est un terme technique quand on parle de C++, qui dont a une definition precise.
Bah oui. En tapant "visibilité poo" sous google, le premier lien est :
http://www.commentcamarche.net/poo/encapsul.php3
qui correspond plutôt à ce que je déclare, et que James Kanze me contredis. Je discute. C'est tout.
C'est une explication qui n'est pas propre au C++ et utilise le terme visibilite dans un sens informel et pas different de celui d'accessibilite. Vu que le terme visibilite a un sens precis en C++, different de celui d'accessibilite l'utiliser dans un sens imprecis ou comme synonyme d'accessibilite va entrainer de la confusion.
Si on prend
class Foo { public: Foo(int); };
class A { public: int g(int); };
class B: public A { public: int f(Foo); int g(Foo); private: int f(int); } b;
Et qu'on considere l'appel b.f(5), int B::f(int) et int B::f(Foo) sont tous deux visibles, donc la resolution de surcharge choisit int B::f(int) mais ce membre n'est pas accessible, donc c'est une erreur.
Si on considere l'appel a.g(5), seul int B::g(Foo) est visible , donc c'est le membre choisit par la resolution de surcharge et il va etre compile parce qu'il y a une conversion implicite de int en Foo (a cause du constructeur de Foo).
Note que int A::g(int) etant cache, ce n'est pas le membre qui sera appele (ce qui peut etre surprenant, tout aussi surprenante est l'erreur qu'on recoit avec b.g(5) quand il n'y a pas de conversion implicite de int en Foo).
Note que d'autres langages ont des regles differentes (si j'ai bonne memoire a des regles de visibilite plus proche de ses regles d'accessibilites).
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
Yoxoman <yoxoman@aol.com> writes:
J'ai l'impression que tu oublies que le terme "visibilite" est un
terme technique quand on parle de C++, qui dont a une definition
precise.
Bah oui. En tapant "visibilité poo" sous google, le premier lien est :
http://www.commentcamarche.net/poo/encapsul.php3
qui correspond plutôt à ce que je déclare, et que James Kanze me
contredis. Je discute. C'est tout.
C'est une explication qui n'est pas propre au C++ et utilise le terme
visibilite dans un sens informel et pas different de celui
d'accessibilite. Vu que le terme visibilite a un sens precis en C++,
different de celui d'accessibilite l'utiliser dans un sens imprecis ou
comme synonyme d'accessibilite va entrainer de la confusion.
Si on prend
class Foo {
public:
Foo(int);
};
class A {
public:
int g(int);
};
class B: public A {
public:
int f(Foo);
int g(Foo);
private:
int f(int);
} b;
Et qu'on considere l'appel b.f(5), int B::f(int) et int B::f(Foo) sont
tous deux visibles, donc la resolution de surcharge choisit int
B::f(int) mais ce membre n'est pas accessible, donc c'est une erreur.
Si on considere l'appel a.g(5), seul int B::g(Foo) est visible , donc
c'est le membre choisit par la resolution de surcharge et il va etre
compile parce qu'il y a une conversion implicite de int en Foo (a
cause du constructeur de Foo).
Note que int A::g(int) etant cache, ce n'est pas le membre qui sera
appele (ce qui peut etre surprenant, tout aussi surprenante est
l'erreur qu'on recoit avec b.g(5) quand il n'y a pas de conversion
implicite de int en Foo).
Note que d'autres langages ont des regles differentes (si j'ai bonne
memoire a des regles de visibilite plus proche de ses regles
d'accessibilites).
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
J'ai l'impression que tu oublies que le terme "visibilite" est un terme technique quand on parle de C++, qui dont a une definition precise.
Bah oui. En tapant "visibilité poo" sous google, le premier lien est :
http://www.commentcamarche.net/poo/encapsul.php3
qui correspond plutôt à ce que je déclare, et que James Kanze me contredis. Je discute. C'est tout.
C'est une explication qui n'est pas propre au C++ et utilise le terme visibilite dans un sens informel et pas different de celui d'accessibilite. Vu que le terme visibilite a un sens precis en C++, different de celui d'accessibilite l'utiliser dans un sens imprecis ou comme synonyme d'accessibilite va entrainer de la confusion.
Si on prend
class Foo { public: Foo(int); };
class A { public: int g(int); };
class B: public A { public: int f(Foo); int g(Foo); private: int f(int); } b;
Et qu'on considere l'appel b.f(5), int B::f(int) et int B::f(Foo) sont tous deux visibles, donc la resolution de surcharge choisit int B::f(int) mais ce membre n'est pas accessible, donc c'est une erreur.
Si on considere l'appel a.g(5), seul int B::g(Foo) est visible , donc c'est le membre choisit par la resolution de surcharge et il va etre compile parce qu'il y a une conversion implicite de int en Foo (a cause du constructeur de Foo).
Note que int A::g(int) etant cache, ce n'est pas le membre qui sera appele (ce qui peut etre surprenant, tout aussi surprenante est l'erreur qu'on recoit avec b.g(5) quand il n'y a pas de conversion implicite de int en Foo).
Note que d'autres langages ont des regles differentes (si j'ai bonne memoire a des regles de visibilite plus proche de ses regles d'accessibilites).
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
Yoxoman
C'est une explication qui n'est pas propre au C++ et utilise le terme visibilite dans un sens informel et pas different de celui d'accessibilite. (...)
Ok. Je comprend mieux la remarque de James Kanze, maintenant. Dialogue de sourds :)
J'avais déja vu ce problème (surcharge qui devient masquage dans des portées différentes) dans le bouquin de Sutter. Mais je n'ai pas dû préter attention au terme visibilité.
Merci pour ces infos.
-- "Yo!" Martin Heidegger
C'est une explication qui n'est pas propre au C++ et utilise le terme
visibilite dans un sens informel et pas different de celui
d'accessibilite.
(...)
Ok. Je comprend mieux la remarque de James Kanze, maintenant. Dialogue
de sourds :)
J'avais déja vu ce problème (surcharge qui devient masquage dans des
portées différentes) dans le bouquin de Sutter. Mais je n'ai pas dû
préter attention au terme visibilité.
C'est une explication qui n'est pas propre au C++ et utilise le terme visibilite dans un sens informel et pas different de celui d'accessibilite. (...)
Ok. Je comprend mieux la remarque de James Kanze, maintenant. Dialogue de sourds :)
J'avais déja vu ce problème (surcharge qui devient masquage dans des portées différentes) dans le bouquin de Sutter. Mais je n'ai pas dû préter attention au terme visibilité.
Merci pour ces infos.
-- "Yo!" Martin Heidegger
kanze
Yoxoman wrote:
J'ai l'impression que tu oublies que le terme "visibilite" est un terme technique quand on parle de C++, qui dont a une definition precise.
Mais je crois que cette utilisation technique n'est pas loin de l'utilisation courante. Est visible ce qu'on peut voir. Et la signification de « private », en C++, c'est grosso modo « régarder (voir) mais non toucher » (ce que me disait toujours ma mère quand j'étais gamin dans un magasin de jouets).
Bah oui. En tapant "visibilité poo" sous google,
Fais gaffe aux informations sur la toile. Il y en a beaucoup plus de fausses que de vraies:-). (Dans ce cas-ci, l'information n'est pas vraiment fausse. Mais il y a une utilisation un peu flou du vocabulaire : parfois, il parle de l'accès, parfois de visibilité, comme s'ils étaient la même chose. Ils ne le sont pas.)
le premier lien est :
http://www.commentcamarche.net/poo/encapsul.php3
qui correspond plutôt à ce que je déclare, et que James Kanze me contredis. Je discute. C'est tout.
Ce n'est pas tellement que je te contredis, mais que je trouve que tu as fais un mauvais choix de vocabulaire. Si tu considères les membres privés comme étant « invisibles », il va y avoir des cas de name binding ou de résolution du surcharge qui vont étonner. Dans ce cas-ci, donc, c'est préférable être précis, d'autant plus que dans Java (que beaucoup de programmeurs connaissent aussi), les spécifications d'accès signifie bien la visibilité.
À titre d'exemple, considère le suivant :
class Base { public: void f( double ) ; } ;
class Intermediaire : public Base { private: void f( int ) ; } ;
class Derived : public Intermediaire { public: void g() { f( 3.14159 ) ; } } ;
En C++, ce code est illégal. L'appel de f dans Derived::g() se résoud à Intermediaire::f(int) ; on essaie donc d'appeler une fonction privée, ce qui est interdit, et on a une erreur de compilateur. Le même code, transcrit en Java, est légal, parce qu'en Java, Intermediaire::f(int) n'est pas visible, et l'appel se résoud à Base::f(double) -- fonction publique. C'est qu'en C++, « private » interdit l'accès, sans jouer sur la visibilité, tandis qu'en Java, il joue sur la visibilité.
Est-ce que tu comprends la différence à laquelle je tiens ? Et pourquoi je le considère importante, où au moins a propos, même si elle paraît subtile ?
-- 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
Yoxoman wrote:
J'ai l'impression que tu oublies que le terme "visibilite"
est un terme technique quand on parle de C++, qui dont a une
definition precise.
Mais je crois que cette utilisation technique n'est pas loin de
l'utilisation courante. Est visible ce qu'on peut voir. Et la
signification de « private », en C++, c'est grosso modo
« régarder (voir) mais non toucher » (ce que me disait toujours
ma mère quand j'étais gamin dans un magasin de jouets).
Bah oui. En tapant "visibilité poo" sous google,
Fais gaffe aux informations sur la toile. Il y en a beaucoup
plus de fausses que de vraies:-). (Dans ce cas-ci, l'information
n'est pas vraiment fausse. Mais il y a une utilisation un peu
flou du vocabulaire : parfois, il parle de l'accès, parfois de
visibilité, comme s'ils étaient la même chose. Ils ne le sont
pas.)
le premier lien est :
http://www.commentcamarche.net/poo/encapsul.php3
qui correspond plutôt à ce que je déclare, et que James Kanze
me contredis. Je discute. C'est tout.
Ce n'est pas tellement que je te contredis, mais que je trouve
que tu as fais un mauvais choix de vocabulaire. Si tu considères
les membres privés comme étant « invisibles », il va y avoir des
cas de name binding ou de résolution du surcharge qui vont
étonner. Dans ce cas-ci, donc, c'est préférable être précis,
d'autant plus que dans Java (que beaucoup de programmeurs
connaissent aussi), les spécifications d'accès signifie bien la
visibilité.
À titre d'exemple, considère le suivant :
class Base
{
public:
void f( double ) ;
} ;
class Intermediaire : public Base
{
private:
void f( int ) ;
} ;
class Derived : public Intermediaire
{
public:
void g()
{
f( 3.14159 ) ;
}
} ;
En C++, ce code est illégal. L'appel de f dans Derived::g() se
résoud à Intermediaire::f(int) ; on essaie donc d'appeler une
fonction privée, ce qui est interdit, et on a une erreur de
compilateur. Le même code, transcrit en Java, est légal, parce
qu'en Java, Intermediaire::f(int) n'est pas visible, et l'appel
se résoud à Base::f(double) -- fonction publique. C'est qu'en
C++, « private » interdit l'accès, sans jouer sur la visibilité,
tandis qu'en Java, il joue sur la visibilité.
Est-ce que tu comprends la différence à laquelle je tiens ? Et
pourquoi je le considère importante, où au moins a propos, même
si elle paraît subtile ?
--
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
J'ai l'impression que tu oublies que le terme "visibilite" est un terme technique quand on parle de C++, qui dont a une definition precise.
Mais je crois que cette utilisation technique n'est pas loin de l'utilisation courante. Est visible ce qu'on peut voir. Et la signification de « private », en C++, c'est grosso modo « régarder (voir) mais non toucher » (ce que me disait toujours ma mère quand j'étais gamin dans un magasin de jouets).
Bah oui. En tapant "visibilité poo" sous google,
Fais gaffe aux informations sur la toile. Il y en a beaucoup plus de fausses que de vraies:-). (Dans ce cas-ci, l'information n'est pas vraiment fausse. Mais il y a une utilisation un peu flou du vocabulaire : parfois, il parle de l'accès, parfois de visibilité, comme s'ils étaient la même chose. Ils ne le sont pas.)
le premier lien est :
http://www.commentcamarche.net/poo/encapsul.php3
qui correspond plutôt à ce que je déclare, et que James Kanze me contredis. Je discute. C'est tout.
Ce n'est pas tellement que je te contredis, mais que je trouve que tu as fais un mauvais choix de vocabulaire. Si tu considères les membres privés comme étant « invisibles », il va y avoir des cas de name binding ou de résolution du surcharge qui vont étonner. Dans ce cas-ci, donc, c'est préférable être précis, d'autant plus que dans Java (que beaucoup de programmeurs connaissent aussi), les spécifications d'accès signifie bien la visibilité.
À titre d'exemple, considère le suivant :
class Base { public: void f( double ) ; } ;
class Intermediaire : public Base { private: void f( int ) ; } ;
class Derived : public Intermediaire { public: void g() { f( 3.14159 ) ; } } ;
En C++, ce code est illégal. L'appel de f dans Derived::g() se résoud à Intermediaire::f(int) ; on essaie donc d'appeler une fonction privée, ce qui est interdit, et on a une erreur de compilateur. Le même code, transcrit en Java, est légal, parce qu'en Java, Intermediaire::f(int) n'est pas visible, et l'appel se résoud à Base::f(double) -- fonction publique. C'est qu'en C++, « private » interdit l'accès, sans jouer sur la visibilité, tandis qu'en Java, il joue sur la visibilité.
Est-ce que tu comprends la différence à laquelle je tiens ? Et pourquoi je le considère importante, où au moins a propos, même si elle paraît subtile ?
-- 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
Yoxoman
(..) C'est qu'en C++, « private » interdit l'accès, sans jouer sur la visibilité, tandis qu'en Java, il joue sur la visibilité.
Je ne savais pas pour Java. C'est très intéressant.
Est-ce que tu comprends la différence à laquelle je tiens ? Et pourquoi je le considère importante, où au moins a propos, même si elle paraît subtile ?
Tout à fait, d'autant que j'approuve cette rigueur vocabularistique. La terminologie me parait particulièrement logique maintenant.
-- "Yo!" Martin Heidegger
(..) C'est qu'en
C++, « private » interdit l'accès, sans jouer sur la visibilité,
tandis qu'en Java, il joue sur la visibilité.
Je ne savais pas pour Java. C'est très intéressant.
Est-ce que tu comprends la différence à laquelle je tiens ? Et
pourquoi je le considère importante, où au moins a propos, même
si elle paraît subtile ?
Tout à fait, d'autant que j'approuve cette rigueur vocabularistique. La
terminologie me parait particulièrement logique maintenant.
(..) C'est qu'en C++, « private » interdit l'accès, sans jouer sur la visibilité, tandis qu'en Java, il joue sur la visibilité.
Je ne savais pas pour Java. C'est très intéressant.
Est-ce que tu comprends la différence à laquelle je tiens ? Et pourquoi je le considère importante, où au moins a propos, même si elle paraît subtile ?
Tout à fait, d'autant que j'approuve cette rigueur vocabularistique. La terminologie me parait particulièrement logique maintenant.
