Discussion :

[nabil.g]

bonsoir,
j'ai le bout de code suivant et je n'arrive pas a r�ellement saisir la logique derri�re.
J'ai deux structure A et B. B est public de A et une m�thode foo virtuelle dans A et �galement d�finie dans B. J'observe que si je fais A* a= new B et que j'appelle a->foo() effectivement la fonction B::foo est appel�e mais avec la valeur du param�tre par defaut de A::foo!
Quelqu'un saurait pourquoi c'est l'argument de la struct A qui est utilis� dans B?

Merci d'avance pour l'explication.
PS: j'utilise g++ version 4.7.3

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
#include<iostream>
struct A{
  virtual int foo(int x=1){
    std::cout << "in A::foo" << std::endl;
    return x*2;
  }
};
struct B: public A{
  int foo(int z=10){
    std::cout << "in B::foo with " << z << std::endl;
    return z*3;
  }
};
int main(){
  A *a = new B;
  std::cout << a->foo() << std::endl;
  return 0;
}

L'output:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
 
in B::foo with 1 <--- ok rentre bien dans foo de B! et z=1 et non pas 10!
3  <-------------------------renvoie z*3 mais utilise pour z la valeur 1 qui est le paramètre par défaut de A::foo!

[Trademark]

Salut,

C'est parce que l'argument par d�faut est d�cid� � la compilation, ce qui signifie que quand ton compilateur va lire la ligne:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

a->foo();

il va regarder le type de a, qui sera A, et "assigner" l'argument par d�faut � ce moment.

[nabil.g]

Merci pour la r�ponse. Donc si je comprends bien toute valeur par d�faut d'un argument d'une m�thode foo d'une classe de base est applique a la m�thode foo de la classe d�riv�e m�me si cette derni�re d�finit une autre valeur par d�faut diff�rente de celle de la classe de base. Ceci n��tant valable que pour les code impl�mentant : A* a = new B;
Merci encore pour la clarification. J'ai appris quelque chose.

[koala01]

Salut,
Non, c'est encore plus vicieux que cela...

Le fait est que le compilateur est un brave petit soldat : il vois un pointeur sur A, il choisit la valeur par d�faut pour A, il voit un pointeur sur B, il choisit la valeur par d�faut pour B.

Ainsi, tu auras plut�t le r�sultat suivant

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
A * ptra=new B;
B * ptrb=new B;
ptra->foo(); // affiche 1
ptrb->foo(); // affiche 10

Ceci dit, d'un point de vue purement conceptuel, l'id�e de changer la valeur par d�faut pour ta classe d�riv�e est assez hummmm... embarrassante ... inqui�tante , je ne trouve pas vraiment le terme

Pour t'aider � comprendre mon malaise :

Il faut savoir que l'h�ritage est une relation EST-UN au sens litt�ral du terme.

Autrement dit, tout objet de type B EST-UN objet de type A, un peu comme une voiture EST-UN v�hicule � moteur.

Du fait de cette relation, tu ne peux pas faire n'importe quoi : Le LSP t'incite � veiller � ce que toute propri�t� valide pour A soit aussi valide pour B, et bon, ca, tu le respecte � peu pr�s, mais il faut aussi te dire:

Primo, que si le d�veloppeur a jug� bon de placer une valeur par d�faut, c'est tr�s certainement qu'il y a bien r�fl�chi et qu'il avait une tr�s bonne raison pour le faire. Essayer de "supplanter" cette valeur par d�faut, revient � nier cette raison.

Secundo, que le LSP est en r�alit� bas� sur une approche appel�e la programmation par contrat.

Cette approche, si on la simplifie � l'extr�me pour l'explication, revient � dire "donne moi ce que je veux, tu auras ce � quoi tu t'attends, mais si tu ne le fais pas, tu peux t'attendre � tout, et surtout au pire".

Enfin, cette approche s'int�resse au conditions pour que l'ex�cution puisse se passer correctement, et fait la distinction entre trois grandes cat�gories:

1. Les pr�conditions : ce sont des conditions qui doivent �tre remplies avant d'essayer de travailler : si tu n'a pas de mortier, tu ne sauras jamais faire tenir tes briques
2. Les postconditions : ce sont des conditions qui doivent �tre v�rifi�es apr�s l'ex�cution : tu ne devras pas casser ton mur et le recommencer que s'il est bien droit, bien rectiligne et � la bonne hauteur.
3. et enfin, les invariants : ce sont des choses qui doivent �tre v�rifi�es en permanence (mais je n'ai pas d'exemple � te donner pour le mur, mais bon, si tu es un homme, le fait de te raser ou de te laisser pousser les cheveux ne fera pas de toi une femme et inversement )

Pour que le syst�me fonctionne, tu ne peux pas faire n'importe quoi avec ces conditions parce que tu risques de te retrouver avec un objet de type B qui est sens� �tre valide mais qui ne remplit pas les conditions pour �tre un A (ce qui est quand m�me malheureux ) ou inversement, de te retrouver avec un objet B qui, quand il est consid�r� comme un A semblerait tout � fait valide mais qui ne serait jamais accept� en tant que B (ce qui serait encore plus malheureux).

Je sens confus�ment que tu ne respectes pas les r�gles en voulant modifier la valeur par d�faut de ton argument.

La meilleure preuve ne est que tu n'obtiens pas du tout le comportement escompt�

Et c'est normal: � partir du moment o� une d�cision de conception est prise, le compilateur n'est absolument pas arm� pour pouvoir d�cider si elle est judicieuse ou non, ce n'est pas son r�le, et il ne saurait pas comment faire.

Il va donc se contenter de l'appliquer du mieux qu'il peut, et tant pis si le comportement semble aberrant

Enfin, tout cela pour dire que voil� un excellent signal d'alarme, qui te fait apprendre � peu de frais.

Parfois, les signaux d'alarmes sont beaucoup plus discrets et les cons�quences beaucoup moins agr�ables

[nabil.g]

Merci pour la r�ponse! en fait ceci fait partie d'un test que j'ai pass� et qui incluait des questions de ce genre. J'essaie la apr�s coup de comprendre mes mauvaises r�ponses. Je fais plus ou moins comme lorsqu'un enseignant vous rend un corrig� et que vous essayez de comprendre pourquoi vous vous �tes mang� afin d��viter de refaire la m�me boulette!
Merci encore.