C++ question de débutant ^^ - Page 6

ca fait con hein, sdommage, on aurait pu faire une mode!
ca sera pour la prochaine fois..

Godzil :
Enfin quel sens tu donne a "Object" ? non pasque est-ce que c'est un Objet a dessiner ? ou est-ce que c'est Objet dans le sens (.net par ex) ou c'est l'objet de base d'ou tout herite ?

"Object", dans mon projet, c'est qlqchose qui a des coordonnées, une largeur/hauteur et qui a la possibilité d'être bougé et dessiné.

Si c'est pas le cas (donc objet qu'on dessine, donc spécifique a ton projet) pourquoi "OpbjetSimpleADessiner" hérite de "Object" ?

J'avais fais hériter "ObjetSimpleADessiner" de "Object", car "ObjetSimpleADessiner" utilise x et y. Mais comme l'on dit spectras et Pollux, ça marchera pas.

En fait t'as plusieurs possibilités selon la sémantique de tes objets :
- ObjetSimpleADessiner hérite de Object, et les objets dessinables héritent uniquement de ObjetsimpleADessiner
=> "Objet1" est un "ObjetsimpleADessiner" qui est un "Object"

- L'utilisation d'un objet-fonction comme indiqué par Neuroo, mais vois plutôt avec lui, c'est quelque chose que je n'utilise jamais (juste parce que je n'en ai pas l'habitude, c'est parfaitement viable sinon).

- Une délégation. ObjetSimpleADessiner contient le code qui sait dessiner, et Objet1 instancie un ObjetSimpleADessiner lors de sa construction, utilisant ses méthodes pour implémenter ses propres fonctions de dessin.

Sémantiquement, je ne vois pas pourquoi Objet1 ne pourrait pas être à la fois un ObjetSimpleADessiner et un ObjetMobile tout en correspondant à une unique instance de Objet, si on ne peut pas le faire c'est juste une limitation du langage ; mais d'un point de vue conceptuel je peux très bien dire : cet objet a toutes les propriétés d'un objet simple à dessiner et aussi toutes les propriétés d'un objet mobile, il est donc utilisable comme l'un ou l'autre (il EST même l'un et l'autre (is-a)), et pourtant ça n'est qu'un seul objet... ^^

après je conçois que ça soit impossible de faire ça en C++, mais je tenais juste à souligner que ce que j'ai dit n'était pas absurde en soi

C'est parfaitement faisable en C++, sauf que ce qu'il veut faire ne correspond pas à ce que tu décris, parce que ObjetSimpleADessiner dépend de ObjetMobile.

Est-ce que plus on inclus de .h, plus la compilation est lente ?
Si oui (ce qui semble logique...), est-ce que en pratique on sent vraiment une différence de vitesse?

faut vraiment en avoir beaucoup pour sentir la difference (pke c juste le preproc qui utilise ca je pense)
pke bon, deja si tu utilises la STL tu dois en avoir qquns ^^ (et templates, donc c'est pire)

spectras :
En fait t'as plusieurs possibilités selon la sémantique de tes objets :
- ObjetSimpleADessiner hérite de Object, et les objets dessinables héritent uniquement de ObjetsimpleADessiner
=> "Objet1" est un "ObjetsimpleADessiner" qui est un "Object"

- L'utilisation d'un objet-fonction comme indiqué par Neuroo, mais vois plutôt avec lui, c'est quelque chose que je n'utilise jamais (juste parce que je n'en ai pas l'habitude, c'est parfaitement viable sinon).

- Une délégation. ObjetSimpleADessiner contient le code qui sait dessiner, et Objet1 instancie un ObjetSimpleADessiner lors de sa construction, utilisant ses méthodes pour implémenter ses propres fonctions de dessin.

Ou encore l'héritage virtuel

J'en ai parlé plus haut, mais ça ne correspond pas à la sémantique de ses objets. L'héritage virtuel aurait un sens si ObjetSimpleADessiner et ObjetMobile héritaient tous deux de ObjetGenerique par exemple. Mais ça ne peut pas marcher, parce que ObjetSimpleADessiner dépend de ObjetMobile.

Est-ce que plus on inclus de .h, plus la compilation est lente ?

Une inclusion c'est ni plus ni moins qu'un copier-coller du fichier inclus.
(éventuellement moins, certains compilateurs étant capables de ni parser un .h qu'une fois même si plusieurs sources l'incluent)

spectras :
J'en ai parlé plus haut, mais ça ne correspond pas à la sémantique de ses objets. L'héritage virtuel aurait un sens si ObjetSimpleADessiner et ObjetMobile héritaient tous deux de ObjetGenerique par exemple. Mais ça ne peut pas marcher, parce que ObjetSimpleADessiner dépend de ObjetMobile.

Euh, je ne vois pas bien ce que tu veux dire ? Tu veux dire que ObjetMobile pourrait avoir une propriété "x" que n'a pas Objet ? Si oui il faudrait aussi que StillObject ait cette propriété "x" (parce que StillObject1 est aussi SimpleADessiner), et à ce moment-là ça ne coûterait rien de mettre cette propriété dans Object lui-même...

(l'héritage virtuel c'est ce qui permet de faire ce que je disais en ./154 ?)

oui ^^

à ce moment-là ça ne coûterait rien de mettre cette propriété dans Object lui-même...

Oui, mais tu changes la sémantique de ses objets en faisant ça. Et au final, vu qu'il n'a que la propriété x dans son exemple, ça revient à faire un héritage normal, MovingObject => ObjetSimpleADessiner => autres trucs.

Gni ? ObjetSimpleADessiner ne peut pas hériter de MovingObject, cf son schéma :

Question: si on fait ne fait pas hériter ObjectSimpleAAfficher de Object, on pourrait pas utiliser des cast à l'intérieur des méthodes de ObjectSimpleAAfficher pour accéder à des variables qui existe dans Object et pas dans ObjectSimpleAAfficher ?

Non.
Enfin c'est peut-être *possible* techniquement d'écrire ça mais c'est difficile de trouver pire comme manière de faire, quand même ^^. Disons que si tu veux vraiment faire ça il vaudrait probablement mieux que tu changes de langage de programmation...

./164> son schéma c'est justement ce que je disais d'éviter ^^

oui enfin avec l'héritage virtuel il peut très bien l'avoir, son schéma...