(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/