Pourquoi faut il déclarer "using Base::foo ;" explicitement dans la
classe fille pour avoir de nouveau accès à Base::foo(int) ?
Après avoir lu les arguments de ce fil de discussion j'aurais tendance
class Base {
void toto( int ) ;
public:
void toto( char* ) ;
} ;
class Derived : public Base {
public:
void toto( double ) ;
void tutu( char* ) { Base::toto(char *); }
} ;
Pourquoi faut il déclarer "using Base::foo ;" explicitement dans la
classe fille pour avoir de nouveau accès à Base::foo(int) ?
Après avoir lu les arguments de ce fil de discussion j'aurais tendance
class Base {
void toto( int ) ;
public:
void toto( char* ) ;
} ;
class Derived : public Base {
public:
void toto( double ) ;
void tutu( char* ) { Base::toto(char *); }
} ;
Pourquoi faut il déclarer "using Base::foo ;" explicitement dans la
classe fille pour avoir de nouveau accès à Base::foo(int) ?
Après avoir lu les arguments de ce fil de discussion j'aurais tendance
class Base {
void toto( int ) ;
public:
void toto( char* ) ;
} ;
class Derived : public Base {
public:
void toto( double ) ;
void tutu( char* ) { Base::toto(char *); }
} ;
Sylvain wrote:James Kanze wrote on 13/05/2006 11:47:Mon point reste. Pour les fonctions privées, toute autre
solution serait problamatique. Du coup, l'argument, c'est
l'orthogonalité -- et c'est un argument du poids, à mon
avis,
c'est à dire ? faut-il comprendre que le compilo va avoir
suffisamment de mal à remonter l'arborescense de classes lors
de la recherche d'une méthode à signature (prototype) donnée,
qu'il sera vraiment en peine de traiter, en plus, un modifier
'public' ou 'private' ??
Le compilateur, non. Mais la règle est plus simple à comprendre
s'il n'y a pas de différence entre la gestion des public et des
private.
Sylvain wrote:
James Kanze wrote on 13/05/2006 11:47:
Mon point reste. Pour les fonctions privées, toute autre
solution serait problamatique. Du coup, l'argument, c'est
l'orthogonalité -- et c'est un argument du poids, à mon
avis,
c'est à dire ? faut-il comprendre que le compilo va avoir
suffisamment de mal à remonter l'arborescense de classes lors
de la recherche d'une méthode à signature (prototype) donnée,
qu'il sera vraiment en peine de traiter, en plus, un modifier
'public' ou 'private' ??
Le compilateur, non. Mais la règle est plus simple à comprendre
s'il n'y a pas de différence entre la gestion des public et des
private.
Sylvain wrote:James Kanze wrote on 13/05/2006 11:47:Mon point reste. Pour les fonctions privées, toute autre
solution serait problamatique. Du coup, l'argument, c'est
l'orthogonalité -- et c'est un argument du poids, à mon
avis,
c'est à dire ? faut-il comprendre que le compilo va avoir
suffisamment de mal à remonter l'arborescense de classes lors
de la recherche d'une méthode à signature (prototype) donnée,
qu'il sera vraiment en peine de traiter, en plus, un modifier
'public' ou 'private' ??
Le compilateur, non. Mais la règle est plus simple à comprendre
s'il n'y a pas de différence entre la gestion des public et des
private.
Jean-Marc Bourguet wrote on 12/05/2006 20:56:Dans ce que tu as coupé il y avait:si j'ai bonne mémoire -- il y a un passage là-dessus dans
D&E, mais je n'ai pas le bouquin ici -- une première version
des règles de résolution de surchage aurait posé des
problèmes -- je ne sais plus lesquels -- qu'on a évité
ainsi. Ensuite les règles de résolution de surchage ont été
modifiée, mais on n'est pas revenu sur ce choix. Quand on
s'en est rendu compte, il y avait trop d'existant.
qui réponds plus ou moins à tes deux questions/objections
(du moins qui donne une spéculation basée sur mes souvenirs
de lecture de D&E).
merci Jean-Marc, j'avais bien lu en effet une spéculation. j'ai préféré
retenir les faits ou informations.
JD a confirmé cet ouvrage (sans l'ombre d'un ombre), donc merci pour cette
référence.
Jean-Marc Bourguet wrote on 12/05/2006 20:56:
Dans ce que tu as coupé il y avait:
si j'ai bonne mémoire -- il y a un passage là-dessus dans
D&E, mais je n'ai pas le bouquin ici -- une première version
des règles de résolution de surchage aurait posé des
problèmes -- je ne sais plus lesquels -- qu'on a évité
ainsi. Ensuite les règles de résolution de surchage ont été
modifiée, mais on n'est pas revenu sur ce choix. Quand on
s'en est rendu compte, il y avait trop d'existant.
qui réponds plus ou moins à tes deux questions/objections
(du moins qui donne une spéculation basée sur mes souvenirs
de lecture de D&E).
merci Jean-Marc, j'avais bien lu en effet une spéculation. j'ai préféré
retenir les faits ou informations.
JD a confirmé cet ouvrage (sans l'ombre d'un ombre), donc merci pour cette
référence.
Jean-Marc Bourguet wrote on 12/05/2006 20:56:Dans ce que tu as coupé il y avait:si j'ai bonne mémoire -- il y a un passage là-dessus dans
D&E, mais je n'ai pas le bouquin ici -- une première version
des règles de résolution de surchage aurait posé des
problèmes -- je ne sais plus lesquels -- qu'on a évité
ainsi. Ensuite les règles de résolution de surchage ont été
modifiée, mais on n'est pas revenu sur ce choix. Quand on
s'en est rendu compte, il y avait trop d'existant.
qui réponds plus ou moins à tes deux questions/objections
(du moins qui donne une spéculation basée sur mes souvenirs
de lecture de D&E).
merci Jean-Marc, j'avais bien lu en effet une spéculation. j'ai préféré
retenir les faits ou informations.
JD a confirmé cet ouvrage (sans l'ombre d'un ombre), donc merci pour cette
référence.
| Moi, ca me semble plus simple a comprendre s'il n'y a pas de
| difference entre visibilite et accessibilite.
hmm, cela me semble un peu surprenant puisque même dans le langage
courant, « accessibilité » != « visibilité ».
| Je suis peut-etre distrait, mais je ne vois pour le moment pas
| d'interet dans cette difference; ca force dans l'ecriture de
| classes derivee a etre conscient de choses dont on ne devrait pas
| s'occuper.
une fonction peut être utile à un conglomerat de classe
uniquement. Dans ce cas, la fonction devrait être accessible à ces
classes et sans leur être invisible.
| Moi, ca me semble plus simple a comprendre s'il n'y a pas de
| difference entre visibilite et accessibilite.
hmm, cela me semble un peu surprenant puisque même dans le langage
courant, « accessibilité » != « visibilité ».
| Je suis peut-etre distrait, mais je ne vois pour le moment pas
| d'interet dans cette difference; ca force dans l'ecriture de
| classes derivee a etre conscient de choses dont on ne devrait pas
| s'occuper.
une fonction peut être utile à un conglomerat de classe
uniquement. Dans ce cas, la fonction devrait être accessible à ces
classes et sans leur être invisible.
| Moi, ca me semble plus simple a comprendre s'il n'y a pas de
| difference entre visibilite et accessibilite.
hmm, cela me semble un peu surprenant puisque même dans le langage
courant, « accessibilité » != « visibilité ».
| Je suis peut-etre distrait, mais je ne vois pour le moment pas
| d'interet dans cette difference; ca force dans l'ecriture de
| classes derivee a etre conscient de choses dont on ne devrait pas
| s'occuper.
une fonction peut être utile à un conglomerat de classe
uniquement. Dans ce cas, la fonction devrait être accessible à ces
classes et sans leur être invisible.
Gabriel Dos Reis writes:| Moi, ca me semble plus simple a comprendre s'il n'y a pas de
| difference entre visibilite et accessibilite.
hmm, cela me semble un peu surprenant puisque même dans le langage
courant, « accessibilité » != « visibilité ».
| Je suis peut-etre distrait, mais je ne vois pour le moment pas
| d'interet dans cette difference; ca force dans l'ecriture de
| classes derivee a etre conscient de choses dont on ne devrait pas
| s'occuper.
une fonction peut être utile à un conglomerat de classe
uniquement. Dans ce cas, la fonction devrait être accessible à ces
classes et sans leur être invisible.
Je me suis peut-etre mal exprime. Je ne vois pas la necessite de
rendre ces concepts orthogonaux dans un langage de programmation. On
peut imaginer que la visibilite implique l'accessibilite et
reciproquement. Ce ne serait plus du C++, nous sommes d'accord. Il y
aurait toujours deux concepts en presence, nous sommes d'accord. Il
n'y aurait qu'un ensemble de regles, ce qui me semble plus simple.
Considerons les deux variables visibilite et accessibilite.
Le cas visible et accessible est utile.
Le cas invisible et inaccessible aussi (meme s'il n'existe pas en C++,
en particulier dans le cadre de la maintenance, ca permet d'ajouter un
membre en etant sur de ne pas impacter le code utilisateur par un
choix malheureux de nom -).
Le cas visible et inaccessible me semble moins utile que le cas
invisible et inaccessible, en particulier je ne vois pas de probleme
qu'il resouds que le second ne resouds pas non plus.
Le cas invisible et accessible me semble tordu (meme si on
n'en est pas loin en C++ avec la supplantation de membres
virtuels prives, mais ce n'est pas exactement la meme chose).
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| Moi, ca me semble plus simple a comprendre s'il n'y a pas de
| difference entre visibilite et accessibilite.
hmm, cela me semble un peu surprenant puisque même dans le langage
courant, « accessibilité » != « visibilité ».
| Je suis peut-etre distrait, mais je ne vois pour le moment pas
| d'interet dans cette difference; ca force dans l'ecriture de
| classes derivee a etre conscient de choses dont on ne devrait pas
| s'occuper.
une fonction peut être utile à un conglomerat de classe
uniquement. Dans ce cas, la fonction devrait être accessible à ces
classes et sans leur être invisible.
Je me suis peut-etre mal exprime. Je ne vois pas la necessite de
rendre ces concepts orthogonaux dans un langage de programmation. On
peut imaginer que la visibilite implique l'accessibilite et
reciproquement. Ce ne serait plus du C++, nous sommes d'accord. Il y
aurait toujours deux concepts en presence, nous sommes d'accord. Il
n'y aurait qu'un ensemble de regles, ce qui me semble plus simple.
Considerons les deux variables visibilite et accessibilite.
Le cas visible et accessible est utile.
Le cas invisible et inaccessible aussi (meme s'il n'existe pas en C++,
en particulier dans le cadre de la maintenance, ca permet d'ajouter un
membre en etant sur de ne pas impacter le code utilisateur par un
choix malheureux de nom -).
Le cas visible et inaccessible me semble moins utile que le cas
invisible et inaccessible, en particulier je ne vois pas de probleme
qu'il resouds que le second ne resouds pas non plus.
Le cas invisible et accessible me semble tordu (meme si on
n'en est pas loin en C++ avec la supplantation de membres
virtuels prives, mais ce n'est pas exactement la meme chose).
Gabriel Dos Reis writes:| Moi, ca me semble plus simple a comprendre s'il n'y a pas de
| difference entre visibilite et accessibilite.
hmm, cela me semble un peu surprenant puisque même dans le langage
courant, « accessibilité » != « visibilité ».
| Je suis peut-etre distrait, mais je ne vois pour le moment pas
| d'interet dans cette difference; ca force dans l'ecriture de
| classes derivee a etre conscient de choses dont on ne devrait pas
| s'occuper.
une fonction peut être utile à un conglomerat de classe
uniquement. Dans ce cas, la fonction devrait être accessible à ces
classes et sans leur être invisible.
Je me suis peut-etre mal exprime. Je ne vois pas la necessite de
rendre ces concepts orthogonaux dans un langage de programmation. On
peut imaginer que la visibilite implique l'accessibilite et
reciproquement. Ce ne serait plus du C++, nous sommes d'accord. Il y
aurait toujours deux concepts en presence, nous sommes d'accord. Il
n'y aurait qu'un ensemble de regles, ce qui me semble plus simple.
Considerons les deux variables visibilite et accessibilite.
Le cas visible et accessible est utile.
Le cas invisible et inaccessible aussi (meme s'il n'existe pas en C++,
en particulier dans le cadre de la maintenance, ca permet d'ajouter un
membre en etant sur de ne pas impacter le code utilisateur par un
choix malheureux de nom -).
Le cas visible et inaccessible me semble moins utile que le cas
invisible et inaccessible, en particulier je ne vois pas de probleme
qu'il resouds que le second ne resouds pas non plus.
Le cas invisible et accessible me semble tordu (meme si on
n'en est pas loin en C++ avec la supplantation de membres
virtuels prives, mais ce n'est pas exactement la meme chose).
Jean-Marc Bourguet writes:
| Gabriel Dos Reis writes:
|
| > | Je suis peut-etre distrait, mais je ne vois pour le moment pas
| > | d'interet dans cette difference; ca force dans l'ecriture de
| > | classes derivee a etre conscient de choses dont on ne devrait pas
| > | s'occuper.
| >
| > une fonction peut être utile à un conglomerat de classe
| > uniquement. Dans ce cas, la fonction devrait être accessible à ces
| > classes et sans leur être invisible.
[...]
| Le cas visible et inaccessible me semble moins utile que le cas
| invisible et inaccessible, en particulier je ne vois pas de probleme
| qu'il resouds que le second ne resouds pas non plus.
L'exemple que j'avais donné dans mon précédent message pointait
justement dans un cas (courant) d'utilisation.
Jean-Marc Bourguet <jm@bourguet.org> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > | Je suis peut-etre distrait, mais je ne vois pour le moment pas
| > | d'interet dans cette difference; ca force dans l'ecriture de
| > | classes derivee a etre conscient de choses dont on ne devrait pas
| > | s'occuper.
| >
| > une fonction peut être utile à un conglomerat de classe
| > uniquement. Dans ce cas, la fonction devrait être accessible à ces
| > classes et sans leur être invisible.
[...]
| Le cas visible et inaccessible me semble moins utile que le cas
| invisible et inaccessible, en particulier je ne vois pas de probleme
| qu'il resouds que le second ne resouds pas non plus.
L'exemple que j'avais donné dans mon précédent message pointait
justement dans un cas (courant) d'utilisation.
Jean-Marc Bourguet writes:
| Gabriel Dos Reis writes:
|
| > | Je suis peut-etre distrait, mais je ne vois pour le moment pas
| > | d'interet dans cette difference; ca force dans l'ecriture de
| > | classes derivee a etre conscient de choses dont on ne devrait pas
| > | s'occuper.
| >
| > une fonction peut être utile à un conglomerat de classe
| > uniquement. Dans ce cas, la fonction devrait être accessible à ces
| > classes et sans leur être invisible.
[...]
| Le cas visible et inaccessible me semble moins utile que le cas
| invisible et inaccessible, en particulier je ne vois pas de probleme
| qu'il resouds que le second ne resouds pas non plus.
L'exemple que j'avais donné dans mon précédent message pointait
justement dans un cas (courant) d'utilisation.
Jean-Marc Bourguet wrote:Le cas visible et inaccessible me semble moins utile que le cas
invisible et inaccessible, en particulier je ne vois pas de
probleme qu'il resouds que le second ne resouds pas non plus.
C'est le cas des fonctions virtuelles privées, par exemple.
Tu ne peux pas appelé la fonction, mais tu peux bien la supplanter.
Je crois aussi qu'une partie du problème se tourne autour de ce
qu'on entend par la visibilité. Un constructeur de copie privé
ferait bien partie de la cas invisible et inaccessible, sauf
qu'il a l'effet bien visible d'inhiber la génération du
constructeur de copie par défaut. Je ne suis pas sûr où le
mettre dans tes catégorisations.
Strictement parlant, évidemment, il n'y a pas de catégorie avec
invisible en C++;
quand tu parles d'invisible et inaccessible, tu parles de ce que tu
veux, non de ce que tu as.
Mais j'ai du mal à voir comment tu catégorises les virtuelles
privées ici -- peut-être je suis en train de me laisser trop
conditionner par Java, mais une fonction invisible virtuelle n'a pas
de sens ; tu ne peux pas la supplanter, parce que si le nom est
invisible, le compilateur doit prendre tes essaies de supplantage
comme la déclaration d'une fonction nouvelle (elle aussi virtuelle).
Donc, par exemple, en Java :
class Base
{
private void f() ;
}
class Derived extends Base
{
public void f() ;
} ;
le f() dans Derived ne supplante pas le f() dans Base -- tout se
passe comme si le f() dans Base n'existait pas.
Je ne suis pas contre une telle catégorie ; elle serait utile
aussi. Mais la catégorie réele de private aujourd'hui -- visible
mais inaccessible -- n'est pas sans intérêt, et m'a bien manqué
quand j'ai fait du Java.
Jean-Marc Bourguet wrote:
Le cas visible et inaccessible me semble moins utile que le cas
invisible et inaccessible, en particulier je ne vois pas de
probleme qu'il resouds que le second ne resouds pas non plus.
C'est le cas des fonctions virtuelles privées, par exemple.
Tu ne peux pas appelé la fonction, mais tu peux bien la supplanter.
Je crois aussi qu'une partie du problème se tourne autour de ce
qu'on entend par la visibilité. Un constructeur de copie privé
ferait bien partie de la cas invisible et inaccessible, sauf
qu'il a l'effet bien visible d'inhiber la génération du
constructeur de copie par défaut. Je ne suis pas sûr où le
mettre dans tes catégorisations.
Strictement parlant, évidemment, il n'y a pas de catégorie avec
invisible en C++;
quand tu parles d'invisible et inaccessible, tu parles de ce que tu
veux, non de ce que tu as.
Mais j'ai du mal à voir comment tu catégorises les virtuelles
privées ici -- peut-être je suis en train de me laisser trop
conditionner par Java, mais une fonction invisible virtuelle n'a pas
de sens ; tu ne peux pas la supplanter, parce que si le nom est
invisible, le compilateur doit prendre tes essaies de supplantage
comme la déclaration d'une fonction nouvelle (elle aussi virtuelle).
Donc, par exemple, en Java :
class Base
{
private void f() ;
}
class Derived extends Base
{
public void f() ;
} ;
le f() dans Derived ne supplante pas le f() dans Base -- tout se
passe comme si le f() dans Base n'existait pas.
Je ne suis pas contre une telle catégorie ; elle serait utile
aussi. Mais la catégorie réele de private aujourd'hui -- visible
mais inaccessible -- n'est pas sans intérêt, et m'a bien manqué
quand j'ai fait du Java.
Jean-Marc Bourguet wrote:Le cas visible et inaccessible me semble moins utile que le cas
invisible et inaccessible, en particulier je ne vois pas de
probleme qu'il resouds que le second ne resouds pas non plus.
C'est le cas des fonctions virtuelles privées, par exemple.
Tu ne peux pas appelé la fonction, mais tu peux bien la supplanter.
Je crois aussi qu'une partie du problème se tourne autour de ce
qu'on entend par la visibilité. Un constructeur de copie privé
ferait bien partie de la cas invisible et inaccessible, sauf
qu'il a l'effet bien visible d'inhiber la génération du
constructeur de copie par défaut. Je ne suis pas sûr où le
mettre dans tes catégorisations.
Strictement parlant, évidemment, il n'y a pas de catégorie avec
invisible en C++;
quand tu parles d'invisible et inaccessible, tu parles de ce que tu
veux, non de ce que tu as.
Mais j'ai du mal à voir comment tu catégorises les virtuelles
privées ici -- peut-être je suis en train de me laisser trop
conditionner par Java, mais une fonction invisible virtuelle n'a pas
de sens ; tu ne peux pas la supplanter, parce que si le nom est
invisible, le compilateur doit prendre tes essaies de supplantage
comme la déclaration d'une fonction nouvelle (elle aussi virtuelle).
Donc, par exemple, en Java :
class Base
{
private void f() ;
}
class Derived extends Base
{
public void f() ;
} ;
le f() dans Derived ne supplante pas le f() dans Base -- tout se
passe comme si le f() dans Base n'existait pas.
Je ne suis pas contre une telle catégorie ; elle serait utile
aussi. Mais la catégorie réele de private aujourd'hui -- visible
mais inaccessible -- n'est pas sans intérêt, et m'a bien manqué
quand j'ai fait du Java.
