Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Ahmed MOHAMED ALI
Bonjour,
void B::Get(param_type3) { // J'appelle ici la classe parente. Get(param_type1); ### Ne compile pas A::Get(param_type1); ### Compile. }
De même si j'instancie B : B* const l_pB = new B;
Si je fais B->Get(param_type1), j'ai la même erreur de compilation, à savoir
param_type1 ne peux être casté en param_type2.
Vous voyez pourquoi ? Je séche là... :-/
A proprement parler, il n'y a pas de problème de polymorphisme dans ton cas, tu n'as pas de méthode virtuelle. C'est normal que B->Get(param_type1) ne compile pas.Dans le classe B, il n' y a pas une telle fonction. Celle héritée de A est masquée par void Get(param_type2) et void Get(param_type3); Pour appeler A::Get ,tu as le choix entre faire un using A::Get dans la classe B ou bien d'appeler la fonction comme ceci : A::Get(...)
Ahmed
"Emmanuel V." wrote in message news:
Bonjour,
J'ai le problème suivant. Schématiquement j'ai :
class A { public: void Get(param_type1); };
class B : public A { public: void Get(param_type2); void Get(param_type3); };
void B::Get(param_type3) { // J'appelle ici la classe parente. Get(param_type1); ### Ne compile pas A::Get(param_type1); ### Compile. }
De même si j'instancie B : B* const l_pB = new B;
Si je fais B->Get(param_type1), j'ai la même erreur de compilation, à savoir
param_type1 ne peux être casté en param_type2.
Vous voyez pourquoi ? Je séche là... :-/
Bonjour,
void B::Get(param_type3)
{
// J'appelle ici la classe parente.
Get(param_type1); ### Ne compile pas
A::Get(param_type1); ### Compile.
}
De même si j'instancie B :
B* const l_pB = new B;
Si je fais B->Get(param_type1), j'ai la même erreur de compilation, à
savoir
param_type1 ne peux être casté en param_type2.
Vous voyez pourquoi ? Je séche là... :-/
A proprement parler, il n'y a pas de problème de polymorphisme dans ton cas,
tu n'as pas de méthode virtuelle.
C'est normal que B->Get(param_type1) ne compile pas.Dans le classe B, il n'
y a pas une telle fonction.
Celle héritée de A est masquée par void Get(param_type2) et void
Get(param_type3);
Pour appeler A::Get ,tu as le choix entre faire un using A::Get dans la
classe B ou bien d'appeler la fonction comme ceci : A::Get(...)
Ahmed
"Emmanuel V." <everguet@vitechnology.com> wrote in message
news:43c87877.0504140729.7caceec3@posting.google.com...
Bonjour,
J'ai le problème suivant. Schématiquement j'ai :
class A
{
public:
void Get(param_type1);
};
class B : public A
{
public:
void Get(param_type2);
void Get(param_type3);
};
void B::Get(param_type3)
{
// J'appelle ici la classe parente.
Get(param_type1); ### Ne compile pas
A::Get(param_type1); ### Compile.
}
De même si j'instancie B :
B* const l_pB = new B;
Si je fais B->Get(param_type1), j'ai la même erreur de compilation, à
savoir
void B::Get(param_type3) { // J'appelle ici la classe parente. Get(param_type1); ### Ne compile pas A::Get(param_type1); ### Compile. }
De même si j'instancie B : B* const l_pB = new B;
Si je fais B->Get(param_type1), j'ai la même erreur de compilation, à savoir
param_type1 ne peux être casté en param_type2.
Vous voyez pourquoi ? Je séche là... :-/
A proprement parler, il n'y a pas de problème de polymorphisme dans ton cas, tu n'as pas de méthode virtuelle. C'est normal que B->Get(param_type1) ne compile pas.Dans le classe B, il n' y a pas une telle fonction. Celle héritée de A est masquée par void Get(param_type2) et void Get(param_type3); Pour appeler A::Get ,tu as le choix entre faire un using A::Get dans la classe B ou bien d'appeler la fonction comme ceci : A::Get(...)
Ahmed
"Emmanuel V." wrote in message news:
Bonjour,
J'ai le problème suivant. Schématiquement j'ai :
class A { public: void Get(param_type1); };
class B : public A { public: void Get(param_type2); void Get(param_type3); };
void B::Get(param_type3) { // J'appelle ici la classe parente. Get(param_type1); ### Ne compile pas A::Get(param_type1); ### Compile. }
De même si j'instancie B : B* const l_pB = new B;
Si je fais B->Get(param_type1), j'ai la même erreur de compilation, à savoir
param_type1 ne peux être casté en param_type2.
Vous voyez pourquoi ? Je séche là... :-/
Vincent Lascaux
Celle héritée de A est masquée par void Get(param_type2) et void Get(param_type3);
Il faut avoué que c'est assez déroutant (moi aussi j'ai été surpris par l'erreur de compilation lorsque le problème m'est apparu pour la première fois. Qu'est ce qui a motivé le choix de ne pas faire comme si on avait écrit using A::foo pour toutes les fonctions foo parentes ?
-- Vincent
Celle héritée de A est masquée par void Get(param_type2) et void
Get(param_type3);
Il faut avoué que c'est assez déroutant (moi aussi j'ai été surpris par
l'erreur de compilation lorsque le problème m'est apparu pour la première
fois. Qu'est ce qui a motivé le choix de ne pas faire comme si on avait
écrit using A::foo pour toutes les fonctions foo parentes ?
Celle héritée de A est masquée par void Get(param_type2) et void Get(param_type3);
Il faut avoué que c'est assez déroutant (moi aussi j'ai été surpris par l'erreur de compilation lorsque le problème m'est apparu pour la première fois. Qu'est ce qui a motivé le choix de ne pas faire comme si on avait écrit using A::foo pour toutes les fonctions foo parentes ?
-- Vincent
Ahmed MOHAMED ALI
Celle héritée de A est masquée par void Get(param_type2) et void Get(param_type3);
Il faut avoué que c'est assez déroutant (moi aussi j'ai été surpris par l'erreur de compilation lorsque le problème m'est apparu pour la première fois. Qu'est ce qui a motivé le choix de ne pas faire comme si on avait écrit using A::foo pour toutes les fonctions foo parentes ?
-- Vincent
En fait, la règle de surcharge des fonctions membres s'inscrit dans une règle plus générale qui veut que les fonctions candidates lors la résolution doivent appartenir à la même portée.Une classe dérivée est située dans une portée différente de sa classe de base,les fonctions de la classe de base ne seront donc pas prises en compte.
Ahmed MOHAMED ALI
"Vincent Lascaux" wrote in message news:425e99e0$0$6560$
Celle héritée de A est masquée par void Get(param_type2) et void Get(param_type3);
Il faut avoué que c'est assez déroutant (moi aussi j'ai été surpris par l'erreur de compilation lorsque le problème m'est apparu pour la première fois. Qu'est ce qui a motivé le choix de ne pas faire comme si on avait écrit using A::foo pour toutes les fonctions foo parentes ?
-- Vincent
Celle héritée de A est masquée par void Get(param_type2) et void
Get(param_type3);
Il faut avoué que c'est assez déroutant (moi aussi j'ai été surpris par
l'erreur de compilation lorsque le problème m'est apparu pour la première
fois. Qu'est ce qui a motivé le choix de ne pas faire comme si on avait
écrit using A::foo pour toutes les fonctions foo parentes ?
--
Vincent
En fait, la règle de surcharge des fonctions membres s'inscrit dans une
règle plus générale qui veut que les fonctions candidates
lors la résolution doivent appartenir à la même portée.Une classe dérivée
est située dans une portée différente de sa classe de base,les
fonctions de la classe de base ne seront donc pas prises en compte.
Ahmed MOHAMED ALI
"Vincent Lascaux" <nospam@nospam.org> wrote in message
news:425e99e0$0$6560$636a15ce@news.free.fr...
Celle héritée de A est masquée par void Get(param_type2) et void
Get(param_type3);
Il faut avoué que c'est assez déroutant (moi aussi j'ai été surpris par
l'erreur de compilation lorsque le problème m'est apparu pour la première
fois. Qu'est ce qui a motivé le choix de ne pas faire comme si on avait
écrit using A::foo pour toutes les fonctions foo parentes ?
Celle héritée de A est masquée par void Get(param_type2) et void Get(param_type3);
Il faut avoué que c'est assez déroutant (moi aussi j'ai été surpris par l'erreur de compilation lorsque le problème m'est apparu pour la première fois. Qu'est ce qui a motivé le choix de ne pas faire comme si on avait écrit using A::foo pour toutes les fonctions foo parentes ?
-- Vincent
En fait, la règle de surcharge des fonctions membres s'inscrit dans une règle plus générale qui veut que les fonctions candidates lors la résolution doivent appartenir à la même portée.Une classe dérivée est située dans une portée différente de sa classe de base,les fonctions de la classe de base ne seront donc pas prises en compte.
Ahmed MOHAMED ALI
"Vincent Lascaux" wrote in message news:425e99e0$0$6560$
Celle héritée de A est masquée par void Get(param_type2) et void Get(param_type3);
Il faut avoué que c'est assez déroutant (moi aussi j'ai été surpris par l'erreur de compilation lorsque le problème m'est apparu pour la première fois. Qu'est ce qui a motivé le choix de ne pas faire comme si on avait écrit using A::foo pour toutes les fonctions foo parentes ?
-- Vincent
everguet
"Ahmed MOHAMED ALI" wrote in message > En fait, la règle de surcharge des fonctions membres s'inscrit dans une
règle plus générale qui veut que les fonctions candidates lors la résolution doivent appartenir à la même portée.Une classe dérivée est située dans une portée différente de sa classe de base,les fonctions de la classe de base ne seront donc pas prises en compte.
Ahmed MOHAMED ALI
Merci pour cette réponse. Ce problème est-il spécifique à C++, ou
existe t-il aussi pour C# ou Java ?
"Ahmed MOHAMED ALI" <ahmedmo@wanadoo.fr> wrote in message > En fait, la règle de surcharge des fonctions membres s'inscrit dans une
règle plus générale qui veut que les fonctions candidates
lors la résolution doivent appartenir à la même portée.Une classe dérivée
est située dans une portée différente de sa classe de base,les
fonctions de la classe de base ne seront donc pas prises en compte.
Ahmed MOHAMED ALI
Merci pour cette réponse. Ce problème est-il spécifique à C++, ou
"Ahmed MOHAMED ALI" wrote in message > En fait, la règle de surcharge des fonctions membres s'inscrit dans une
règle plus générale qui veut que les fonctions candidates lors la résolution doivent appartenir à la même portée.Une classe dérivée est située dans une portée différente de sa classe de base,les fonctions de la classe de base ne seront donc pas prises en compte.
Ahmed MOHAMED ALI
Merci pour cette réponse. Ce problème est-il spécifique à C++, ou
existe t-il aussi pour C# ou Java ?
kanze
Vincent Lascaux wrote:
Celle héritée de A est masquée par void Get(param_type2) et void Get(param_type3);
Il faut avoué que c'est assez déroutant (moi aussi j'ai été surpris par l'erreur de compilation lorsque le problème m'est apparu pour la première fois. Qu'est ce qui a motivé le choix de ne pas faire comme si on avait écrit using A::foo pour toutes les fonctions foo parentes ?
La cohérence, peut-être. En général, on cherche un symbole jusqu'à le trouver, pas plus loin. Ce sont des portées différentes.
Côté pratique, je crois qu'une des motivations était d'empécher que l'addition d'une fonction dans une classe de base puisse modifier la sémantique de la classe dérivée. Donc, si dans la classe dérivée, j'ai défini une fonction f(int), et que je l'appelle avec un char, l'ajonction d'une fonction f(char) dans la classe de base ne doit pas changer la résolution du surcharge.
-- 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
Vincent Lascaux wrote:
Celle héritée de A est masquée par void Get(param_type2) et
void Get(param_type3);
Il faut avoué que c'est assez déroutant (moi aussi j'ai été
surpris par l'erreur de compilation lorsque le problème m'est
apparu pour la première fois. Qu'est ce qui a motivé le choix
de ne pas faire comme si on avait écrit using A::foo pour
toutes les fonctions foo parentes ?
La cohérence, peut-être. En général, on cherche un symbole
jusqu'à le trouver, pas plus loin. Ce sont des portées
différentes.
Côté pratique, je crois qu'une des motivations était d'empécher
que l'addition d'une fonction dans une classe de base puisse
modifier la sémantique de la classe dérivée. Donc, si dans la
classe dérivée, j'ai défini une fonction f(int), et que je
l'appelle avec un char, l'ajonction d'une fonction f(char) dans
la classe de base ne doit pas changer la résolution du
surcharge.
--
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
Celle héritée de A est masquée par void Get(param_type2) et void Get(param_type3);
Il faut avoué que c'est assez déroutant (moi aussi j'ai été surpris par l'erreur de compilation lorsque le problème m'est apparu pour la première fois. Qu'est ce qui a motivé le choix de ne pas faire comme si on avait écrit using A::foo pour toutes les fonctions foo parentes ?
La cohérence, peut-être. En général, on cherche un symbole jusqu'à le trouver, pas plus loin. Ce sont des portées différentes.
Côté pratique, je crois qu'une des motivations était d'empécher que l'addition d'une fonction dans une classe de base puisse modifier la sémantique de la classe dérivée. Donc, si dans la classe dérivée, j'ai défini une fonction f(int), et que je l'appelle avec un char, l'ajonction d'une fonction f(char) dans la classe de base ne doit pas changer la résolution du surcharge.
-- 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
Emmanuel V. wrote:
"Ahmed MOHAMED ALI" wrote in message
En fait, la règle de surcharge des fonctions membres s'inscrit dans une règle plus générale qui veut que les fonctions candidates lors la résolution doivent appartenir à la même portée.Une classe dérivée est située dans une portée différente de sa classe de base,les fonctions de la classe de base ne seront donc pas prises en compte.
Merci pour cette réponse. Ce problème est-il spécifique à C++, ou existe t-il aussi pour C# ou Java ?
Je ne connais pas le C#, mais quant à Java : la situation n'est pas tout à fait identique en Java, dans la mésure où il n'y a pas de fonctions globales. La règle Java est donc qu'on cherche la fonction partout où c'est visible, dans toutes les portées. Toujours.
En revanche, on a toujours le problème en Java qu'ajouter une fonction avec le même nom dans une classe de base peut modifier le comportement de la classe dérivée, d'une façon pas forcément prévisible. Le problème est attenué du fait que les fonctions privées ne sont pas visibles dans les classes dérivées, mais il existe quand même.
-- 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
Emmanuel V. wrote:
"Ahmed MOHAMED ALI" <ahmedmo@wanadoo.fr> wrote in message
En fait, la règle de surcharge des fonctions membres
s'inscrit dans une règle plus générale qui veut que les
fonctions candidates lors la résolution doivent appartenir à
la même portée.Une classe dérivée est située dans une portée
différente de sa classe de base,les fonctions de la classe
de base ne seront donc pas prises en compte.
Merci pour cette réponse. Ce problème est-il spécifique à C++,
ou existe t-il aussi pour C# ou Java ?
Je ne connais pas le C#, mais quant à Java : la situation n'est
pas tout à fait identique en Java, dans la mésure où il n'y a
pas de fonctions globales. La règle Java est donc qu'on cherche
la fonction partout où c'est visible, dans toutes les portées.
Toujours.
En revanche, on a toujours le problème en Java qu'ajouter une
fonction avec le même nom dans une classe de base peut modifier
le comportement de la classe dérivée, d'une façon pas forcément
prévisible. Le problème est attenué du fait que les fonctions
privées ne sont pas visibles dans les classes dérivées, mais il
existe quand même.
--
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
En fait, la règle de surcharge des fonctions membres s'inscrit dans une règle plus générale qui veut que les fonctions candidates lors la résolution doivent appartenir à la même portée.Une classe dérivée est située dans une portée différente de sa classe de base,les fonctions de la classe de base ne seront donc pas prises en compte.
Merci pour cette réponse. Ce problème est-il spécifique à C++, ou existe t-il aussi pour C# ou Java ?
Je ne connais pas le C#, mais quant à Java : la situation n'est pas tout à fait identique en Java, dans la mésure où il n'y a pas de fonctions globales. La règle Java est donc qu'on cherche la fonction partout où c'est visible, dans toutes les portées. Toujours.
En revanche, on a toujours le problème en Java qu'ajouter une fonction avec le même nom dans une classe de base peut modifier le comportement de la classe dérivée, d'une façon pas forcément prévisible. Le problème est attenué du fait que les fonctions privées ne sont pas visibles dans les classes dérivées, mais il existe quand même.
-- 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
