(Courriels de diversion: <meuglement@enivrerez-postdatera.com> <sympas@chariots-alfa.com> <vitrifieras@demaquillent-tondra.com> <prospectrice@assistent-souvenant.com> <accostent@bohemiennes-recriminiez.com> <transcription@scolariserait-cuti-reaction.com> <aspergeons@radiodiffuses-degrossissaient.com> <refugies@sous-estimions-particularises.com> <embrayons@ravives-galvaniserez.com> <tuerez@erres-trituraient.com> )


Le 10 Mar, Guylhem XXXX écrit :
> On Wed, Mar 10, 1999 at 01:02:21AM +0100, Pierre Baudracco wrote:
>> Regarde ce que ca donne si tu change le nom de ta classe exception.
>> par exemple My_exception a la place de exception.
>  
> Bien sur, j'ai essayé (Marc Thirion me l'a aussi conseillé) mais alors
> il m'avait sorti un truc encore plus stérile :
> g++ -c -I.. -fno-implicit-templates -g exception.cc
> /usr/include/g++/stl_uninitialized.h: In function `ForwardIterator
> __uninitialized_copy_aux(InputIterator, InputIterator, ForwardIterator,
> struct __false_type)':
> In file included from /usr/include/g++/algobase.h:39,
>                  from /usr/include/g++/list.h:30,
>                  from ../ui/user_interface.h:6,
>                  from screen.h:6,
>                  from exception.cc:22:

  Donc, c'est bien, puisqu'il plante plus loin, et sur autre chose. Tu
as donc progressé en changeant le nom de la classe exception définie
par l'application.
  Je trouve louche que tu aies des fichiers inclus venant de
répertoires */egcs-xxx/* et de répertoires */g++/* ; tu es sûr que
c'est normal ?

>> Sinon le probleme vient de la. Redefinition.
> 
> En C++, n'est-ce pas prévu ???? C'est ce qui me pose le pb de
> compréhension...

  Je pense que tu confonds : tu ne peux pas redéfinir une classe. Tu
peux « redéfinir » des fonctions (le terme est plutôt mal choisi). Tu
as trois mécanisme que tu peux appeler « redéfinition ».
  Le premier, la plus simple, envoie les appels sur le même code : tu
redéclare la fonction en précisant des valeurs par défaut des
paramètres :
  int f(char c, int i) {...}  // définition
  ...
  f('a', 3); /* en C++, 'a' est de type char ; en C, de type int ; une
     des différences entre ces langages */
  ...
  int f(char c, int i = 5); // déclaration avec paramètre par défaut
  ...
  f('a'); // appelle la même fonction, avec i == 5

  Le deuxième est résolu à la compilation : tu as des codes différents,
mais le même nom ; la distinction est faite par le compilateur suivant
le type des paramètres (les type lors de la compilation, bien sûr, pas
letype à l'exécution en cas de polymorphisme) :
  int f(char c); // f1
  int f(int i);  // f2
  f('a'); // -> f1
  f(3);   // -> f2
 Le plus simple est de se souvenir que le nom ne suffit pas pour savoir
de quelle fonction iol est question : il faut le nom et le type des
paramètres.
  Ce mécanisme est nommé « surcharge ».

  Le troisième (celui que l'on nomme habituellement « redéfinition »),
est résolu à l'exécution ; il ne fonctionne qu'avec les fonctions
membres des classes.
  class A {
     virtual int f(char a) {} // f1
  }
  class B: public A { /* B hérite de A (B est dérivée de la classe de
                         base A */
    int f(char a) {} // f2 ; le virtual est optionnel ici
  }
  A *a1 = new A;
  A *a2 = new B; /* polymorphisme : uniquement sur les pointeurs et les
                    références. */
  B *b = new B;

  a1 ->f('a'); // -> f1
  a2 ->f('a'); // -> f2
  b ->f('a'); // -> f2

  Ce mécanisme est nommé « liaison dynamique ».

  Evidemment, cela se complique quand on mélange les trois à la fois (ce
langage est ignoble).

-- 
Marc Thirion             | Toulouse, France
Un Travail pour Chacun   : http://www.multimania.com/untravailchacun/



 _______________________________________________________________________
  Le CULTe sur le ouebe: http://savage.iut-blagnac.fr/