J'ai une classe enfant qui hérite de d'une classe parent.
J'ai écrit le constructeur de parent (celui sans parametre) et quand je fais
un new enfant, le constructeur de parent est bien appelé.
J'ai aussi écrit un autre constructeur pour parent (avec un parametre) et
quand je fais un new enfant(1), le compilateur me dit qu'il ne trouve pas le
constructeur ! pourquoi ?
| Ce que je cherche à comprendre, c'est pourquoi il n'applique pas la meme | logique sur les constructeurs ?
parce qu'un constructeur n'est pas une fonction normale et ne s'hérite pas.
| pour moi un constructeur c'est une simple fonction appelée automatique à la | création d'un objet mais je ne vois pas en quoi cela n'empèche pas de gérer | la surcharge comme pour l'exemple ci-dessus.
un constructeur n'est pas une simple fonction. C'est une fonction spéciale.
-- Gaby
"PurL" <purl-nospam@chez.com> writes:
| Ce que je cherche à comprendre, c'est pourquoi il n'applique pas la meme
| logique sur les constructeurs ?
parce qu'un constructeur n'est pas une fonction normale et ne
s'hérite pas.
| pour moi un constructeur c'est une simple fonction appelée automatique à la
| création d'un objet mais je ne vois pas en quoi cela n'empèche pas de gérer
| la surcharge comme pour l'exemple ci-dessus.
un constructeur n'est pas une simple fonction. C'est une fonction spéciale.
| Ce que je cherche à comprendre, c'est pourquoi il n'applique pas la meme | logique sur les constructeurs ?
parce qu'un constructeur n'est pas une fonction normale et ne s'hérite pas.
| pour moi un constructeur c'est une simple fonction appelée automatique à la | création d'un objet mais je ne vois pas en quoi cela n'empèche pas de gérer | la surcharge comme pour l'exemple ci-dessus.
un constructeur n'est pas une simple fonction. C'est une fonction spéciale.
-- Gaby
PurL
un constructeur n'est pas une simple fonction. C'est une fonction spéciale.
Mouai, bon bah je suis pas plus avancé :((
PurL
un constructeur n'est pas une simple fonction. C'est une fonction
spéciale.
un constructeur n'est pas une simple fonction. C'est une fonction spéciale.
Mouai, bon bah je suis pas plus avancé :((
PurL
Benoit Rousseau
PurL wrote:
un constructeur n'est pas une simple fonction. C'est une fonction spéciale.
Mouai, bon bah je suis pas plus avancé :((
PurL
Bein si... tu sais comment appeler un constructeur d'une classe mère à
partir de la classe fille maintenant... Ce n'est pas beaucoup de code en plus :
class A { public A() { ... }; };
class B : public A { public B() : A() {}; //Les accolades peuvent être vide };
-- -------------------------------------------- Benoît Rousseau : roussebe at spray dot se Jouez en programmant : http://realtimebattle.sourceforge.net/
PurL wrote:
un constructeur n'est pas une simple fonction. C'est une fonction
spéciale.
Mouai, bon bah je suis pas plus avancé :((
PurL
Bein si... tu sais comment appeler un constructeur d'une classe mère à
partir de la classe fille maintenant... Ce n'est pas beaucoup de code en
plus :
class A {
public A() { ... };
};
class B : public A {
public B() : A() {}; //Les accolades peuvent être vide
};
--
--------------------------------------------
Benoît Rousseau : roussebe at spray dot se
Jouez en programmant : http://realtimebattle.sourceforge.net/
un constructeur n'est pas une simple fonction. C'est une fonction spéciale.
Mouai, bon bah je suis pas plus avancé :((
PurL
Bein si... tu sais comment appeler un constructeur d'une classe mère à
partir de la classe fille maintenant... Ce n'est pas beaucoup de code en plus :
class A { public A() { ... }; };
class B : public A { public B() : A() {}; //Les accolades peuvent être vide };
-- -------------------------------------------- Benoît Rousseau : roussebe at spray dot se Jouez en programmant : http://realtimebattle.sourceforge.net/
Gabriel Dos Reis
"PurL" writes:
| > un constructeur n'est pas une simple fonction. C'est une fonction | > spéciale. | | Mouai, bon bah je suis pas plus avancé :((
Je peux rien pour toi. Un constructeur ne s'hérite pas et ce n'est pas ma volonté.
-- Gaby
"PurL" <purl-nospam@chez.com> writes:
| > un constructeur n'est pas une simple fonction. C'est une fonction
| > spéciale.
|
| Mouai, bon bah je suis pas plus avancé :((
Je peux rien pour toi. Un constructeur ne s'hérite pas et ce n'est pas
ma volonté.
| > un constructeur n'est pas une simple fonction. C'est une fonction | > spéciale. | | Mouai, bon bah je suis pas plus avancé :((
Je peux rien pour toi. Un constructeur ne s'hérite pas et ce n'est pas ma volonté.
-- Gaby
Marc Boyer
PurL wrote:
et le compilateur mettrait quoi comme valeurs pour les paramètres ? Bah les valeurs fournies à la création de enfant :
et pourquoi ?
Pour les memes raisons que dans cette exemple :
Reprenons: considères-tu que class X { int i; } est équivalent à class X { int i; public: X(){}; } c'est à dire que définir un constructeur qui fait la même chose que me constructeur par défaut est équivalent à ne rien faire ?
Dès lors, te souviens-tu des règles de redéfinitions ? struct A { f(double d); } struct B: public A { f(); } void foo(){ A a; B b; a.f(1.2); // OK b.f(); // OK b.f(); // KO, ne compile pas }
Dès lors, si le constructeur est une méthode comme les autres, et si ne pas définir de constructeur revient à définir un constructeur sans paramêtre, alors ton constructeur par défaut, sans paramêtre, masque le constructeur avec paramêtres.
pour moi un constructeur c'est une simple fonction appelée automatique à la création d'un objet mais je ne vois pas en quoi cela n'empèche pas de gérer la surcharge comme pour l'exemple ci-dessus.
Parce que l'absence de constructeur est grosso-modo la définition d'un constructeur sans paramêtre, et que dès lors, il n'y a plus surcharge mais redéfinition.
Marc Boyer, pas sur que son explication soit la seule, ni historiquement celle qui a fait penché la balance, mais ça se tient. -- Lying for having sex or lying for making war? Trust US presidents :-(
PurL wrote:
et le compilateur mettrait quoi comme valeurs pour les paramètres ?
Bah les valeurs fournies à la création de enfant :
et pourquoi ?
Pour les memes raisons que dans cette exemple :
Reprenons: considères-tu que
class X { int i; }
est équivalent à
class X { int i; public: X(){}; }
c'est à dire que définir un constructeur qui fait la même
chose que me constructeur par défaut est équivalent à ne
rien faire ?
Dès lors, te souviens-tu des règles de redéfinitions ?
struct A { f(double d); }
struct B: public A { f(); }
void foo(){
A a;
B b;
a.f(1.2); // OK
b.f(); // OK
b.f(); // KO, ne compile pas
}
Dès lors, si le constructeur est une méthode comme les
autres, et si ne pas définir de constructeur revient
à définir un constructeur sans paramêtre, alors
ton constructeur par défaut, sans paramêtre, masque
le constructeur avec paramêtres.
pour moi un constructeur c'est une simple fonction appelée automatique à la
création d'un objet mais je ne vois pas en quoi cela n'empèche pas de gérer
la surcharge comme pour l'exemple ci-dessus.
Parce que l'absence de constructeur est grosso-modo la
définition d'un constructeur sans paramêtre, et que dès lors,
il n'y a plus surcharge mais redéfinition.
Marc Boyer, pas sur que son explication soit la seule, ni
historiquement celle qui a fait penché la balance, mais
ça se tient.
--
Lying for having sex or lying for making war? Trust US presidents :-(
et le compilateur mettrait quoi comme valeurs pour les paramètres ? Bah les valeurs fournies à la création de enfant :
et pourquoi ?
Pour les memes raisons que dans cette exemple :
Reprenons: considères-tu que class X { int i; } est équivalent à class X { int i; public: X(){}; } c'est à dire que définir un constructeur qui fait la même chose que me constructeur par défaut est équivalent à ne rien faire ?
Dès lors, te souviens-tu des règles de redéfinitions ? struct A { f(double d); } struct B: public A { f(); } void foo(){ A a; B b; a.f(1.2); // OK b.f(); // OK b.f(); // KO, ne compile pas }
Dès lors, si le constructeur est une méthode comme les autres, et si ne pas définir de constructeur revient à définir un constructeur sans paramêtre, alors ton constructeur par défaut, sans paramêtre, masque le constructeur avec paramêtres.
pour moi un constructeur c'est une simple fonction appelée automatique à la création d'un objet mais je ne vois pas en quoi cela n'empèche pas de gérer la surcharge comme pour l'exemple ci-dessus.
Parce que l'absence de constructeur est grosso-modo la définition d'un constructeur sans paramêtre, et que dès lors, il n'y a plus surcharge mais redéfinition.
Marc Boyer, pas sur que son explication soit la seule, ni historiquement celle qui a fait penché la balance, mais ça se tient. -- Lying for having sex or lying for making war? Trust US presidents :-(
Marc Boyer
In article <bog9k2$gli$, PurL wrote:
un constructeur n'est pas une simple fonction. C'est une fonction spéciale.
Mouai, bon bah je suis pas plus avancé :((
Notons que c'est le constructeur qui fixe les règles de résolution des fonctions virtuelles, alors que les autres les suivent.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
In article <bog9k2$gli$1@news-reader5.wanadoo.fr>, PurL wrote:
un constructeur n'est pas une simple fonction. C'est une fonction
spéciale.
Mouai, bon bah je suis pas plus avancé :((
Notons que c'est le constructeur qui fixe les règles de
résolution des fonctions virtuelles, alors que les autres
les suivent.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Le code est bon, mais je me suis planté entre redéfinition et masquage... La malédiction du Vendredi a encore frappé.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
kanze
"PurL" wrote in message news:<bofl0v$qks$...
Benoit Rousseau wrote:
PurL wrote:
J'ai une classe enfant qui hérite de d'une classe parent.
J'ai écrit le constructeur de parent (celui sans parametre) et quand je fais un new enfant, le constructeur de parent est bien appelé. J'ai aussi écrit un autre constructeur pour parent (avec un parametre) et quand je fais un new enfant(1), le compilateur me dit qu'il ne trouve pas le constructeur ! pourquoi ?
Parceque personne n'appelle le constructeur de parent si tu ne le fais pas. enfant doit aussi avoir ses constructeurs qui appeleront les constructeurs de parent : enfant::enfant() : parent() { ... }
Merci de ta réponse.
Mais dans ce premier cas, il n'est pas nécessaire d'écrire le constructeur sans parametre pour enfant. Le compilateur appelle celui du parent.
enfant::enfant( int i ) : parent( i ) { ... }
Bonne réponse, mais je ne comprends pas pourquoi le compilateur peut appeler le constructeur par défaut de parent à partir d'enfant, il peut aussi appeler les fonctions publiques (avec ou sans parametres) de parent à partir d'enfant - et tout ça sans écrire le moindre code dans enfant - mais il peut pas appeler implicitement les constructeurs avec parametres de parent à partir d'enfant ! Je vois pas la raison de cette limitation...
Parce que le langage est fait comme ça, pour beaucoup de raisons. Le compilateur ne peut fournir que deux types de constructeurs : des constructeurs par défaut (sans paramètres) et des constructeurs par copie. Dans les deux cas, les motivations initiales pour permettre au compilateur de les fournir sont liées à la compatibilité C, et au fait qu'en C++, une classe et une struct sont la même chose. (Certains regrettent qu'on soit obligé à en avoir ces deux.)
On pourrait envisagé ajouter des défauts, en particulier, celui que tu proposes. Mais ce n'est pas si évident que tu as l'air de penser. Considérons, par exemple :
class A { public : A( int ) ; } ; class B { public : B( double ) ; } ;
class C : public A, public B {} ;
Qu'est-ce qu'il faudrait faire dans ce cas-là, par exemple ?
Dans l'ensemble, ce que tu veux faire n'est valable que dans un nombre assez restreint des cas.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"PurL" <purl-nospam@chez.com> wrote in message
news:<bofl0v$qks$1@news-reader4.wanadoo.fr>...
Benoit Rousseau wrote:
PurL wrote:
J'ai une classe enfant qui hérite de d'une classe parent.
J'ai écrit le constructeur de parent (celui sans parametre) et
quand je fais un new enfant, le constructeur de parent est bien
appelé. J'ai aussi écrit un autre constructeur pour parent (avec un
parametre) et quand je fais un new enfant(1), le compilateur me dit
qu'il ne trouve pas le constructeur ! pourquoi ?
Parceque personne n'appelle le constructeur de parent si tu ne le
fais pas. enfant doit aussi avoir ses constructeurs qui appeleront
les constructeurs de parent :
enfant::enfant() : parent() {
...
}
Merci de ta réponse.
Mais dans ce premier cas, il n'est pas nécessaire d'écrire le
constructeur sans parametre pour enfant. Le compilateur appelle celui
du parent.
enfant::enfant( int i ) : parent( i ) {
...
}
Bonne réponse, mais je ne comprends pas pourquoi le compilateur peut
appeler le constructeur par défaut de parent à partir d'enfant, il
peut aussi appeler les fonctions publiques (avec ou sans parametres)
de parent à partir d'enfant - et tout ça sans écrire le moindre code
dans enfant - mais il peut pas appeler implicitement les constructeurs
avec parametres de parent à partir d'enfant ! Je vois pas la raison de
cette limitation...
Parce que le langage est fait comme ça, pour beaucoup de raisons. Le
compilateur ne peut fournir que deux types de constructeurs : des
constructeurs par défaut (sans paramètres) et des constructeurs par
copie. Dans les deux cas, les motivations initiales pour permettre au
compilateur de les fournir sont liées à la compatibilité C, et au fait
qu'en C++, une classe et une struct sont la même chose. (Certains
regrettent qu'on soit obligé à en avoir ces deux.)
On pourrait envisagé ajouter des défauts, en particulier, celui que tu
proposes. Mais ce n'est pas si évident que tu as l'air de penser.
Considérons, par exemple :
class A { public : A( int ) ; } ;
class B { public : B( double ) ; } ;
class C : public A, public B {} ;
Qu'est-ce qu'il faudrait faire dans ce cas-là, par exemple ?
Dans l'ensemble, ce que tu veux faire n'est valable que dans un nombre
assez restreint des cas.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
J'ai une classe enfant qui hérite de d'une classe parent.
J'ai écrit le constructeur de parent (celui sans parametre) et quand je fais un new enfant, le constructeur de parent est bien appelé. J'ai aussi écrit un autre constructeur pour parent (avec un parametre) et quand je fais un new enfant(1), le compilateur me dit qu'il ne trouve pas le constructeur ! pourquoi ?
Parceque personne n'appelle le constructeur de parent si tu ne le fais pas. enfant doit aussi avoir ses constructeurs qui appeleront les constructeurs de parent : enfant::enfant() : parent() { ... }
Merci de ta réponse.
Mais dans ce premier cas, il n'est pas nécessaire d'écrire le constructeur sans parametre pour enfant. Le compilateur appelle celui du parent.
enfant::enfant( int i ) : parent( i ) { ... }
Bonne réponse, mais je ne comprends pas pourquoi le compilateur peut appeler le constructeur par défaut de parent à partir d'enfant, il peut aussi appeler les fonctions publiques (avec ou sans parametres) de parent à partir d'enfant - et tout ça sans écrire le moindre code dans enfant - mais il peut pas appeler implicitement les constructeurs avec parametres de parent à partir d'enfant ! Je vois pas la raison de cette limitation...
Parce que le langage est fait comme ça, pour beaucoup de raisons. Le compilateur ne peut fournir que deux types de constructeurs : des constructeurs par défaut (sans paramètres) et des constructeurs par copie. Dans les deux cas, les motivations initiales pour permettre au compilateur de les fournir sont liées à la compatibilité C, et au fait qu'en C++, une classe et une struct sont la même chose. (Certains regrettent qu'on soit obligé à en avoir ces deux.)
On pourrait envisagé ajouter des défauts, en particulier, celui que tu proposes. Mais ce n'est pas si évident que tu as l'air de penser. Considérons, par exemple :
class A { public : A( int ) ; } ; class B { public : B( double ) ; } ;
class C : public A, public B {} ;
Qu'est-ce qu'il faudrait faire dans ce cas-là, par exemple ?
Dans l'ensemble, ce que tu veux faire n'est valable que dans un nombre assez restreint des cas.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
PurL
On pourrait envisagé ajouter des défauts, en particulier, celui que tu proposes. Mais ce n'est pas si évident que tu as l'air de penser. Considérons, par exemple :
class A { public : A( int ) ; } ; class B { public : B( double ) ; } ;
class C : public A, public B {} ;
Qu'est-ce qu'il faudrait faire dans ce cas-là, par exemple ?
Effectivement dans ce cas, cela pose un pb.
Dans l'ensemble, ce que tu veux faire n'est valable que dans un nombre assez restreint des cas.
Merci de cette réponse. Faudrait pouvoir le mettre en fluo pour signaler que c'est le seul recevable de ce thread.
PurL
On pourrait envisagé ajouter des défauts, en particulier, celui que tu
proposes. Mais ce n'est pas si évident que tu as l'air de penser.
Considérons, par exemple :
class A { public : A( int ) ; } ;
class B { public : B( double ) ; } ;
class C : public A, public B {} ;
Qu'est-ce qu'il faudrait faire dans ce cas-là, par exemple ?
Effectivement dans ce cas, cela pose un pb.
Dans l'ensemble, ce que tu veux faire n'est valable que dans un nombre
assez restreint des cas.
Merci de cette réponse.
Faudrait pouvoir le mettre en fluo pour signaler que c'est le seul recevable
de ce thread.
On pourrait envisagé ajouter des défauts, en particulier, celui que tu proposes. Mais ce n'est pas si évident que tu as l'air de penser. Considérons, par exemple :
class A { public : A( int ) ; } ; class B { public : B( double ) ; } ;
class C : public A, public B {} ;
Qu'est-ce qu'il faudrait faire dans ce cas-là, par exemple ?
Effectivement dans ce cas, cela pose un pb.
Dans l'ensemble, ce que tu veux faire n'est valable que dans un nombre assez restreint des cas.
Merci de cette réponse. Faudrait pouvoir le mettre en fluo pour signaler que c'est le seul recevable de ce thread.
PurL
Marc Boyer
PurL wrote:
Dans l'ensemble, ce que tu veux faire n'est valable que dans un nombre assez restreint des cas.
Merci de cette réponse. Faudrait pouvoir le mettre en fluo pour signaler que c'est le seul recevable de ce thread.
Parce que mes explications sur le masquage et la redéfinition, c'était de la merde ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
PurL wrote:
Dans l'ensemble, ce que tu veux faire n'est valable que dans un nombre
assez restreint des cas.
Merci de cette réponse.
Faudrait pouvoir le mettre en fluo pour signaler que c'est le seul recevable
de ce thread.
Parce que mes explications sur le masquage et la redéfinition,
c'était de la merde ?
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
