Discussion :

[kromartien]

Bonjour.

Je voudrai savoir si la POO a été inventée comme formalisme pour se départir de certains problèmes techniques tels que la gestion de la mémoire, où si elle a plutôt été inventée pour simplifier les implémentations et la structuration des données.

Je voudrais savoir en fait, en réponse à quels problèmes la POO est-elle devenue une façon de programmer distincte de la programmation en général et dans quel contexte?

Tout cela pour en savoir plus sur la nécessité de posséder un formalisme objet pour un programmeur.

Merci beaucoup pour vos réponses.

[Woufeil]

Salut,

Je te fais un quote de mon cours sur la POO en Perl :

La POO est une méthode de programmation née de réflexions sur la qualité et le coût de la création et de l'entretien d'un programme. En effet, il a été constaté que de 70 à 80% du coût d'un programme provient de la phase de maintenance et non de celle de création pure.
La but de la POO est de réduire ce coût. Pour cela, on a fixé des critères de qualité d'un programme OO. Ils sont au nombre de 4 :
la Validité : respect du cahier des charges
l'Extensibilité : permettre l'ajout de fonctionnalités
la Réutilisabilité : permettre l'utilisation d'un même composant pour différentes applications
la Robustesse : consiste en un traitement des exceptions.

Ca, c'est ce que l'on m'a appris en cours. Après, techniquement parlant, je ne pense pas que l'un des buts de la POO soit de ne plus avoir à gérer la mémoire : un langage de haut niveau comme Perl disposait d'un garbage collector et d'un typage dynamique bien avant de proposer des fonctions permettant de faire de la POO. Je dirais que ce sont deux thèmes indépendants.

[souviron34]

Pour cela, on a fixé des critères de qualité d'un programme OO. Ils sont au nombre de 4 :
la Validité : respect du cahier des charges
l'Extensibilité : permettre l'ajout de fonctionnalités
la Réutilisabilité : permettre l'utilisation d'un même composant pour différentes applications
la Robustesse : consiste en un traitement des exceptions.

Le gars qui t'as enseigné ça est bien ...

Ces 4 critères sont 4 critères de la qualité d'un logiciel. Je ne vois pas en quoi ils sont particulièrement des critères de POO.



Je pense que le fond de la POO est de définir une structuration de langage se rapprochant de l'analyse d'un problème et de sa solution.

En effet, on n'a pas attendu les langages objets pour faire de la POO. Pourquoi ?

Simplement parce que les problèmes ne se posent pas en termes informatiques, mais en termes fonctionnels.

Exemple : un programme de traitement d'image.

• Lecture d'une image A
• Lecture d'une image B
• Addition image A et image B
• Sauvegarde image résultat

On voit vien ici qu'on a une notion d'image, et que l'on fait des opérations sur cet "objet".

Et c'est valable pour une écrasante majorité de problèmes.


Donc on a tenté de définir un paradigme et éventuellement un (et des) langage(s) pour formaliser l'interaction entre la description d'un problème et sa programmation.

Mais soyons précis : comme répété à de nombreuses reprises, la POO n'a pas besoin de langages objet.

Comme dans l'exemple ci-dessus, ce style de programme, bien que de conception POO, peut être fait en Assembleur, en Fortran, en C, en Pascal, bref en n'importe quel langage informatique.

Et si les 4 critères énoncés ci-dessus n'étaient valables que pour la POO, il y aurait eu un nombre incalculable de catastrophes au cours des 50 dernières années...

[Woufeil]

Je pense que tu n'as pas bien compris ce que voulais dire mon prof. Bien entendu que ces quatre critères sont nécessaires s'appliquent à n'importe quel logiciel (j'imagine bien un programme qui ne respecte pas le cahier des charges ). Ce qu'il voulait dire, c'est que la POO permet de faciliter la mise en œuvre de ces critères. Personnellement, je trouve ça tout à fait exact...

[Jean-Marc.Bourguet]

Bonjour. Je voudrai savoir si la POO a été inventée comme formalisme pour se départir de certains problèmes techniques tels que la gestion de la mémoire, où si elle a plutôt été inventée pour simplifier les implémentations et la structuration des données.

D'après Alan Kay (inventeur du terme), une des deux motivations centrales derrière la POO, c'était de trouver une meilleure méthode de modulariser les système complexe.

Je voudrais savoir en fait, en réponse à quels problèmes la POO est-elle devenue une façon de programmer distincte de la programmation en général, dans quel contexte, par qui, comment, pourquoi?

J'ai du mal à répondre à la question, car je ne considère pas la prémisse (à savoir que la POO est une façon de programmer distincte de la programmation en général) comme vraie.

Je vois la POO comme étant l'aboutissement (actuel?) d'un des trois grands paradigme de programmation: la programmation impérative (les deux autres étant la programmation fonctionnelle et la programmation logique).

Tout cela pour en savoir plus sur la nécessité de posséder un formalisme objet pour un programmeur.

C'est une des techniques de conception les plus utilisées -- pas la seule et pas adaptée à tous les problèmes. Ne pas en avoir au moins des notions me semble un fameux trou dans les connaissances pour un programmeur.

[Jean-Marc.Bourguet]

Mais soyons précis : comme répété à de nombreuses reprises, la POO n'a pas besoin de langages objet.

Nous sommes d'accord. Mais sans langage objet, faire de la POO est plus compliqué. Les définitions de ce qu'est la POO sont variées et pas toutes d'accord entre elles. Ma perception c'est que c'est un terme qui a été (est encore?) à la mode et comme toujours dans ce genre de cas, il fini à la fois par perdre tout sens (parce que chacun le redéfini en fonction de ses intérêts) et par devenir une religion (parce que ne pas être POO est devenu mal).

Le seul point commun que j'ai trouvé (qui permette en particulier de comprendre des opinions consensuelles comme le fait qu'Ada83 ou Obéron ne sont pas des langages OO tandis qu'Ada95 et Obéron-2 le sont), c'est l'utilisation du polymorphisme d'inclusion combiné avec une surcharge résolue dynamiquement.

Et donc exemple tombe court, ni l'un, ni l'autre n'y sont employés. En le complètant tu peux arriver à une conception qui est OO (par exemple dans sa gestion des formats d'image) ou qui ne l'est pas.

Et oui, il est possible de le faire comme Monsieur Jourdain faisait de la prose, mais c'est beaucoup plus facile quand on en est conscient. Et on peut considérer que l'émergence de la POO résulte de la prise de conscience de l'existance d'un Design Pattern (pour utiliser un autre terme qui a été à la mode bien après) suivit de la décision de créer des langages et des techniques de conception adaptés.

[souviron34]

je suis assez d'accord avec toi sur ce sujet...

Disons qu'on confond usuellement 3 choses :

• 1 Conception orientée objet
• 2 Programmation orientée objet
• 3 Langages objets

Et ce qui m'énerve un peu (tu as dû le remarquer ) dans effectivement la "mode" actuelle, c'est le fait de considérer l'équivalence des 3, et que par conséquent si tu ne connais pas le 3 par exemple, tu ne peux décemment pas faire du 1 ou du 2...


Quand tu dis :

polymorphisme d'inclusion combiné avec une surcharge résolue dynamiquement

pour moi c'est du chinois... Franchement je ne comprend pas ce que ça veut dire. Et c'est bien là-dessus que je te rejoins dans ce que tu dis sur la mode et les définitions et la "religion" etc..

Par contre quand tu dis :

Mais sans langage objet, faire de la POO est plus compliqué

là je ne suis plus...

C'est plus compliqué pour quelqu'un qui n'a pas "l'esprit objet", et que les langages forcent à utiliser la notion.

Mais pour quelqu'un qui maîtrise un langage de programmation, quel qu'il soit, et qui a "l'esprit objet", non ça n'est pas compliqué.


Je pense profondément qu'il faudrait avant tout s'assurer que les programmeurs (mais les profs ne suivent pas non plus ) font de la CONCEPTION orientée objet.

Ceci fait, la PROGRAMMATION orientée objet en découle, et ce quel que soit le langage.

Après, pour les plus "flemmards" (sans vouloir partir de troll ) ou les plus "habitués à la programmation via des outils tout faits" ou les plus "formés à tel ou tel langage", le LANGAGE objet peut être utilisé.

En fait, tout vient de la phrase

"ce qui se conçoit bien s'énonce clairement" ....

[EDIT]

En fait je dirais par rapport au PO :

NON

mais

de la nécessité de la COO

[/EDIT]

[Jean-Marc.Bourguet]

pour moi c'est du chinois...

En gros, utilisation des fonctions virtuelles en C++. Plus en détail:
http://www.bourguet.org/cpp/type.pdf

Par contre quand tu dis :

Mais sans langage objet, faire de la POO est plus compliqué

là je ne suis plus...

C'est plus compliqué pour quelqu'un qui n'a pas "l'esprit objet", et que les langages forcent à utiliser la notion. [/quote]

Il n'y a pas à être forcé (on n'est pas forcé en C++). Mais faire l'équivalent de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
struct M {
   virtual void f1();
   virtual void f2(int);
};

struct F : M {
   void f1();
   void f2(int);
};

void foo(M* ptr) {
   ptr->f1();
   ptr->f2(42);
}

en C n'est pas si évident que cela. La technique est bien connue, mais l'utiliser sans le support d'un framework bâtit à l'aide de macros, c'est pas le plus naturel. J'ai écrit de tel framework (pour du C et pour de l'assembleur). Mais je continue à préférer un langage conçu avec un support natif.

Après, pour les plus "flemmards" (sans vouloir partir de troll ) ou les plus "habitués à la programmation via des outils tout faits" ou les plus "formés à tel ou tel langage", le LANGAGE objet peut être utilisé.

Tu me places dans quelle catégorie?

A te lire, je me demande parfois si tu as compris ce qu'est la POO.

[souviron34]

non non il n'y a rien de personnel dans mes remarques


Je citais, par rapport au nombre de programmeurs actuels et leur historique, ce qui me semble être la vraie "argumentation profonde" , qui n'est pas théorique, mais à mon avis bien plutôt pratique, pour la cote d'amour actuelle de la POO.

Quant à ton exemple, si il fait bien ce que je crois comprendre (définir une structure M contenant 2 fonctions inconnues, une sans argument et une avec, une structure F de type M et quelles sont les fonctions f1 et f2 (une instance, pour utiliser les termes), et une fonction foo qui appelle ces fonctions via la structure générique), c'est pas trivial parce que pas utilisé si fréquemment et donc pas enseigné, mais c'est aussi facile en C.

Quand tu cites Molière, je ne suis pas certain "qu'il soit plus facile de faire de la prose quand on en est conscient"... N'est pas écrivain qui veut, même si on a appris à écrire et qu'on nous dit que "on peut le faire"...

Si tu veux, en gros, pour moi , la POO est une manière d'écrire un programme qui suit la COO.

Sans plus.

[Edit]

Et en relisant, sur ta remarque sur mon petit exemple, je conteste

Pour moi , dès que l'on identifie un CONCEPT et qu'on lui attribue des ATTRIBUTS et des METHODES/OPERATIONS, on fait de la COO.

Donc un programme de traitement d'image dont la conception implique la création d'un concept "image" avec des attributs (origine, dimensions, nom) et des opérations manipulant ces "concepts" pour donner un résultat du même type EST un programme POO.

[/Edit]

[Jean-Marc.Bourguet]

c'est aussi facile en C.

Montre. Après je te donnerais la deuxième partie du programme C++ (celle qui contient le main et l'appel a foo).

Quand tu cites Molière, je ne suis pas certain "qu'il soit plus facile de faire de la prose quand on en est conscient"...

Si le but est d'écrire de la prose, il vaut mieux savoir ce qu'est la prose, au risque, pour son malheur, de se retrouver rimailleur.

Donc un programme de traitement d'image dont la conception implique la création d'un concept "image" avec des attributs (origine, dimensions, nom) et des opérations manipulant ces "concepts" pour donner un résultat du même type EST un programme POO.

On peut être d'accord si tu admets que c'est un cas dégénéré. Le coeur de la COO est de manipuler indépendant des concepts liés.

[souviron34]

Voici pour le code avec l'appel :

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
#include <stdio.h>
#include <stdlib.h>

typedef void f1(void);
typedef void f2(int entier);

typedef struct pM {
  f1 *FF1 ;
  f2 *FF2 ;
} M ;


void foo ( M *S )
{
  S->FF1();
  S->FF2(42);
}


void FF1 ( void )
{
  fprintf ( stderr, "\nAppel fonction type f1\n");
}

void FF2 ( int A )
{
  fprintf ( stderr, "\nAppel fonction type f2 Résultat %d\n",A);
}

  
int main(int argc, char *argv[])
{
  M F ;
  
  F.FF1 = FF1 ;
  F.FF2 = FF2 ;

  foo(&F);

  return 0;
}

Comme tu vois pas vraiment plus compliqué

Quant au "dégénéré", je ne sais pas ce que tu entends par là...

La manipulation indépendante de concepts liés ....

Comme je dis, assez trivial quand on possède son sujet..

[Jean-Marc.Bourguet]

Voici pour le code avec l'appel :

Comme tu vois pas vraiment plus compliqué

Je vois surtout les problemes; tu es meme tombe dans ceux que je pensais que tu allais eviter etant donne tes references a X et Motif... Pour te donner une piste, voici l'appel auquel je pensais.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
struct F2: F {
   void f1() { f2(x); }
   int x;
}

int main() {
   F2 i;
   i.f1();
}

Et j'ai ete gentil, j'ai pas utilise l'heritage multiple.

Quant au "dégénéré", je ne sais pas ce que tu entends par là...

De meme que travailler avec des entiers peut etre considere comme un cas degenere du travail avec des reels, de meme que travailler avec des triangles peut etre considere comme un cas degenere du travail avec des quadrilateres, une conception orientee objet qui ne fait pas usage de l'heritage est un cas degenere.

[kromartien]

Bonjour.

Vous semblez dire que la Conception Orientée Objet est bien quelque chose à part qui se distingue vraiment du langage C.

Bien que l'on puisse définir en C des objets et des méthodes associées (constructeur, destructeur) , ce qui donne au C une parentée avec la programmation orientée objet, Jean-Marc.Bourguet met en avant le concept d'héritage de classe, qui distingue d'après lui la 'véritable' programmation orientée objet des bidouillages C (POO dégénérée dit-il) associés.

Je me demandais si au contraire ce n'est pas l'utilisation des langages impératifs, proches de la machine (tels le C), qui ont menés au développement des langages objets afin de faciliter la manipulation de concepts, ou alors, si à l'inverse c'est au C, destiné néanmoins à être proche de la machine, que l'on a voulu attribuer le maximum de caractéristiques de 'Programmation Orientée Objet' ?

Et donc, comme la distinction entre C et C++ (C++ orienté objet) est faite, je voudrai savoir à quels besoins non satisfaits par le C les mécanismes d'héritage répondent-ils.

[Woufeil]

Juste histoire de rajouter mon grain de sel niveau vocabulaire...

C++ n'est pas un langage objet, pas plus que Java. Smalltalk en revanche en est un, car tout est objet en Smalltalk.

Il y a une autre nuance plus intéressante, c'est celle qu'à souligné Jean Marc. Pour qu'un langage soit considéré comme un langage OO, il faut effectivement qu'il supporte le polymorphisme et la surcharge résolue dynamiquement. Sinon, on parle de langage basé objet.

Même sans utiliser deux fonctions virtuelles, ce que je ne vois pas en C, c'est comment régler ce problème :

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
Class C1 {
    virtual void f ();
};

Class C2 : C1 {
    void f ();
};

void foo (C1 objet)
{
    objet.f(); //Sans dynamisme, ce sera toujours la méthode de C1 qui sera utilisée
}

int main {
    C1 objet1;
    C2 objet 2;
    foo (objet1);
    foo (objet2);
};

Je ne vois vraiment pas comment appeler la bonne méthode sans le mot clé virtual...

[Jean-Marc.Bourguet]

Vous semblez dire que la Conception Orientée Objet est bien quelque chose à part qui se distingue vraiment du langage C.

Une technique de conception se distingue vraiment d'un langage, quel qu'il soit.

On peut mettre en oeuvre une conception OO en C d'au moins deux manieres:
- a la main; c'est pas aussi simple que Souviron34 veut le croire, mais ce n'est pas insurmontable. Le probleme principal va etre la tentation de prendre des raccourcis, d'"optimiser" en fonction du cas particulier, et le risque de se retrouver bloque pour l'evolution future si le cas particulier n'est plus valable.
- avec un framework; on se retrouve a programmer en fait dans un nouveau langage legerement different du C et suivant la maniere dont le framework est mis en oeuvre, avec le probleme de devoir debugger au niveau C quand on a ecrit autre chose.

Bien que l'on puisse définir en C des objets et des méthodes associées (constructeur, destructeur) , ce qui donne au C une parentée avec la programmation orientée objet, Jean-Marc.Bourguet met en avant le concept d'héritage de classe, qui distingue d'après lui la 'véritable' programmation orientée objet des bidouillages C (POO dégénérée dit-il) associés.

L'heritage n'est pas reellement necessaire. La possibilite d'avoir des objets qui sont de plusieurs types l'est. Et la possibilite d'avoir une resolution de surcharge tenant compte des aspects dynamiques de l'objet et pas uniquement son type statique.

Ce que j'appelai POO degeneree, ce n'est pas l'utilisation du C, c'est l'aboutissement de la technique de conception OO a une structure qui n'utilise pas ces notions, qu'elle soit mise en oeuvre en C, en C++ ou en SmallTalk.

Je me demandais si au contraire ce n'est pas l'utilisation des langages impératifs, proches de la machine (tels le C), qui ont menés au développement des langages objets afin de faciliter la manipulation de concepts, ou alors, si à l'inverse c'est au C, destiné néanmoins à être proche de la machine, que l'on a voulu attribuer le maximum de caractéristiques de 'Programmation Orientée Objet' ?

Les langages OO sont l'aboutissement actuel de la lignee des langages imperatifs. Le C est caracteristique d'une etape anterieure de cette evolution; il a pourtant suffisemment de mecanisme de bas niveau pour permettre d'implementer les mecanismes necessaires pour faire de l'OO -- ce qui n'est pas le cas de tous les langages concus a ce stade.

Et donc, comme la distinction entre C et C++ (C++ orienté objet) est faite, je voudrai savoir à quels besoins non satisfaits par le C les mécanismes d'héritage répondent-ils.

Le C++ est plus que du C avec de l'OO. C'est du C avec
- un systeme de type plus sur, permettant un meilleur controle de la modularite (les notions de private/public par exemple ne sont en rien OO et sont plutot representatives d'une etape intermediaire entre le C et le C++ dans l'evolution des concepts de programmation)
- de l'oriente objet
- de la programmation generique (les templates), qui est un sujet totalement different de l'OO

[souviron34]

Je vois surtout les problemes; tu es meme tombe dans ceux que je pensais que tu allais eviter etant donne tes references a X et Motif... Pour te donner une piste, voici l'appel auquel je pensais.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
struct F2: F {
   void f1() { f2(x); }
   int x;
}

int main() {
   F2 i;
   i.f1();
}

Et j'ai ete gentil, j'ai pas utilise l'heritage multiple.

Je reprend :

Peux-tu expliciter en français ce que tu veux faire ? Ne connaissant pas C++, je ne comprends pas exactement (et si je comprend, je ne vois pas en quoi ma réponse à ton exemple a des problèmes).


Et donne-moi un exemple d'héritage multiple, et on va voir

De meme que travailler avec des entiers peut etre considere comme un cas degenere du travail avec des reels, de meme que travailler avec des triangles peut etre considere comme un cas degenere du travail avec des quadrilateres, une conception orientee objet qui ne fait pas usage de l'heritage est un cas degenere.

ET ?? Je ne vois pas en quoi, dans tout ce que j'ai dit plus haut, on ne peut pas considérer que l'on peut faire de l'héritage en C..

(comme tu cites X et Motif, ne serait-ce que la XToolkit : il y a définition d'un Widget Core, et ensuite tous les Widgets héritent de ça, de même qu'un WMShell hérite d'un VMShell qui hérite d'un Shell qui hérite d'un Core, et pourtant c'est du C).

En résumé je ne vois pas en quoi quand je dis que le point important est que la CONCEPTION soit orientée objet, tu en déduis qu'en dehors des langages objets c'est un cas dégénéré.

Même sans utiliser deux fonctions virtuelles, ce que je ne vois pas en C, c'est comment régler ce problème

Même question qu'à Jean-Marc : en texte lisible, que veux-tu faire ? Encore une fois si je comprend correctement, c'est implicite que c'est fait avec l'exemple donné ci-dessus...


Je reviens profondément au sujet du PO et à ce que je disais :

Je suis d'accord pour dire qu'un langage PEUT faciliter la programmation, mais comme je mentionnais, je pense que l'on fait beaucoup de bruit autour de quelque chose qui n'est QU'UN OUTIL.

Ce que je conteste, c'est de tirer un lien direct entre CONCEPTION orientée objet et LANGAGE objet.

Et je ré-itère que les notions d'héritages, et de ce que vous semblez appeler "polymorphisme dynamique" (qui, comme je le répète pour moi sont des mots dont je ne comprend pas la signifcation telle quelle car ils supposent une "formation" adaptée) sont courants EN DEHORS DES LANGAGES OBJETS (bon, courant peut-être pas, mais suffisamment utilisés pour ne pas être exceptionnels).

Je dirais que le seul langage "objet" réel que j'ai rencontré (je n'ai pas fait se SmallTalk) (et bien que l'on ne le dénomme pas de cette manière) a été Prolog. Là oui la traduction n'est pas évidente dans un autre langage.

Mais encore une fois si une CONCEPTION a été faire correctement, il n'y a pas de problèmes.

[Edit]

Jean-Marc, j'aimerais que tu explicites un peu cette phrase stp :

L'heritage n'est pas reellement necessaire. La possibilite d'avoir des objets qui sont de plusieurs types l'est. Et la possibilite d'avoir une resolution de surcharge tenant compte des aspects dynamiques de l'objet et pas uniquement son type statique.

Car si je le comprend correctement, je ne vois pas en quoi cela serait impossible de manière simple (mais pas forcément facilement compréhensible pour un néophyte) en C.

Je crois que j'ai trouvé..

En fait, je pense que notre point d'achoppement (et je reviens à ce que je disais plus haut) est le fait que cela soit facile ou non à comprendre par des débutants ou quasi-débutants..

[/Edit]

[Woufeil]

Personnellement, je n'ai jamais vu de polymorphisme dans un langage non OO. Pour ce qui est de ce que je te demande de faire en C, je vais te remettre le même code, mais commenté :

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
20
Class C1 {
    virtual void f (); //virtual permet de surcharger cette méthode pour les classes enfants
};

Class C2 : C1 { //on précise que C2 hérite de C1
    void f (); //ici, on surcharge la méthode f de la classe C1
};

void foo (C1 objet) //ici, C peut être indifféremment un objet de la classe C1 ou C2
//cela est dû au fait que C2 hérite de C1 (C2 IS A C1)
{
    objet.f(); //selon que C soit de la classe C1 ou C2, cet appel ne devrait pas invoquer la même méthode
}

int main {
    C1 objet1;
    C2 objet 2;
    foo (objet1); //ici, je veux appeler C1.f()
    foo (objet2); //ici, je veux appeler C2.f()
};

Voilà, j'espère que c'est plus clair pour toi.

[souviron34]

ok merci avant de répondre encore une petite précision de vocabulaire :

par "surcharger" tu veux dire "remplacer" c'est ça ?

[Woufeil]

ok merci avant de répondre encore une petite précision de vocabulaire :

par "surcharger" tu veux dire "remplacer" c'est ça ?

Je dirais plutôt redéfinir que remplacer, mais le principe est le même oui
En gros, si l'on appelle la méthode f avec la classe C2, ce n'est pas censé faire la même chose que si on le fait avec C1.

Par contre, une autre particularité de l'héritage non présentée dans mes exemples (mais que tu dois connaitre), si la méthode bar membre de la classe C1 n'est pas surchargée dans C2, alors c'est elle qui devra être appelée si on l'appelle avec un objet de classe C2. Je le dis pour faciliter la compréhension

[souviron34]

ok merci.. J'étais pris aujourdhui et encore demain, mais je regarderais en début d'après midi..

Dernière précision :

l'écriture

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
struct F2: F {
   void f1() { f2(x); }
   int x;
}

signifie que F2 hérite de F , c'est ça ? c'est à dire contient F, mais n'est pas du même type.. (surensemble)