Discussion :

[koala01]

<Modération>
Cette discussion est issue de :
http://www.developpez.net/forums/d12...eur-pointeurs/
</Modération>

Bonjour,

Étant un peu en avance à un TP, mon prof de C++ m'a demandé de faire en sorte de redéfinir bool operator<(Creature *, Creature *).

Humm...

De toute évidence, ta classe Creature a sémantique d'entité, à moins que je ne me trompe lourdement

A ce titre, tu peux, peut etre, envisager de comparer certains états en ajoutant des fonctions ou foncteur prenant deux pointeurs sur Creature et comparant les états en question.

Mais il me semble pour le moins difficile d'envisager de comparer deux instances de Creature (surtout si elles sont d'un type dynamique différent) autrement que... par leur adresse mémoire .

Le problème est, comme tout le monde le sait, qu'une adresse mémoire (surtout allouée de manière dynamique) dépend de tellement de paramètres que leur comparaison n'offre aucune garantie de reproductivité :

Il ne serait pas étonnant outre mesure que, en générant deux fois une situation similaire (même nombre de créatures et autres éléments, générés selon la même logique, etc ) on en arrive à des situations où un tri basé sur les adresses mémoires donnerait un résultat totalement différent pour cause de critères totalement indépendants du programme

Dés lors, la question se pose plus que sérieusement : quel intérêt pourrait avoir un tel opérateur voir une fonction / un foncteur fournissant un tel comportement

[Neckara]

Humm...

De toute évidence, ta classe Creature a sémantique d'entité, à moins que je ne me trompe lourdement

A ce titre, tu peux, peut etre, envisager de comparer certains états en ajoutant des fonctions ou foncteur prenant deux pointeurs sur Creature et comparant les états en question.

Mais il me semble pour le moins difficile d'envisager de comparer deux instances de Creature (surtout si elles sont d'un type dynamique différent) autrement que... par leur adresse mémoire .

Le problème est, comme tout le monde le sait, qu'une adresse mémoire (surtout allouée de manière dynamique) dépend de tellement de paramètres que leur comparaison n'offre aucune garantie de reproductivité :

Il ne serait pas étonnant outre mesure que, en générant deux fois une situation similaire (même nombre de créatures et autres éléments, générés selon la même logique, etc ) on en arrive à des situations où un tri basé sur les adresses mémoires donnerait un résultat totalement différent pour cause de critères totalement indépendants du programme

Dés lors, la question se pose plus que sérieusement : quel intérêt pourrait avoir un tel opérateur voir une fonction / un foncteur fournissant un tel comportement

Je n'avais aucun problème à ce niveau là, mon TP était déjà fini.

Là ce que je cherchais à faire, c'était de remplacer un foncteur qui compare les PV des créatures par l'opérateur< pour ne plus à avoir à le renseigner lors de l'appel d'algorithmes de la STL sur un std::list<Creature *>.

Après comme je l'ai dit plus haut, le mieux aurait été d'utiliser les shared_ptr à la place de pointeurs et là j'aurais pu redéfinir l'opérateur<.

[koala01]

Je n'avais aucun problème à ce niveau là, mon TP était déjà fini.

Là ce que je cherchais à faire, c'était de remplacer un foncteur qui compare les PV des créatures par l'opérateur< pour ne plus à avoir à le renseigner lors de l'appel d'algorithmes de la STL sur un std::list<Creature *>.

J'aurais envie de dire que tu n'as pas à le faire...

Le foncteur représente, exactement, ce qu'il te faut où il le faut, et ce, pour au moins trois bonne raisons:

1. Tu compares, avec le foncteur, un état bien particulier existant pour les deux instances de la classe, ce qui fait que tu pourrais très bien envisager de comparer d'autres états, comme la force, le courage, l'agressivité ou que sais-je
2. Tu as appliqué, en choisissant de créer un foncteur, un principe très important, qui nécessite souvent une refonte de code pour l'appliquer "sur le tard" mais qui ne doit jamais être défait : celui de la responsabilité unique / de la délégation des responsabilités. Maintenant que tu as retiré, par la création du foncteur, la responsabilité de la comparaison d'un état entre deux instances de la classe, il serait particulièrement dommage (et illogique ) de revenir en arrière
3. L'opérateur "<" signifie, faut il le rappeler... plus petit... S'agissant de créatures, le fait de restreindre la comparaison à leur seul nombre de point de vie semble particulièrement restrictif : une créature plus agile ou plus forte, ou avec une meilleure armure ou de meilleures armes ayant moins de point de vie qu'une autre n'est pas "forcément" plus petite qu'une créature n'ayant que "d'avantage de points de vie"

Non, décidément, je crois sincèrement qu'il vaut mieux argumenter auprès de ton prof pour lui faire comprendre que c'est une mauvaise idée que d'essayer de le satisfaire "quoi qu'il en coute"

Mes interventions t'auront sans doute (enfin, je l'espère) donné quelques pistes intéressantes pour l'argumentaire

[Neckara]

C'est un TP, les créature n'ont qu'un nom et des points de vies.
Après il y a deux types de créatures :
- Troll : qui sont lourd (et qui active un des piège) ;
- Gobelin : léger et rapides, ils n'encaissent que la moitié des dégâts.

Après le but n'est pas d'améliorer le code le plus possible (c'est qu'un TP après tout) mais d'essayer de voir si on peut le faire ou non.

C'est comme essayer de kill init sous Linux, ça ne sert à rien mais ça nous amuse^^

[koala01]

C'est un TP, les créature n'ont qu'un nom et des points de vies.
Après il y a deux types de créatures :
- Troll : qui sont lourd (et qui active un des piège) ;
- Gobelin : léger et rapides, ils n'encaissent que la moitié des dégâts.

Après le but n'est pas d'améliorer le code le plus possible (c'est qu'un TP après tout)

J'ai toujours eu une simple horreur du pincipe du "ce n'est qu'un TP après tout"...

Que tu fasses involontairement des erreurs dans un TP, c'est normal et c'est le but du TP : c'est par tes erreurs que tu apprendras le plus.

Par contre, tu dois aborder un TP exactement de la même manière que n'importe quel projet : en y mettant la même rigueur et le meilleur de toi-même.

Si tu n'apprends pas la rigueur à l'occasion d'un TP, tu ne l'auras pas dans tes projets réels, et si tu te dis que "ce n'est pas grave si j'introduis volontairement une erreur dans un TP", tu vas prendre l'habitude de "cataloguer" tes projets en fonction de la rigueur dont tu dois faire preuve lors du développement.

Or, pour ton client ou ton employeur, tout projet ne peut être considéré que comme... "critique", aussi simple et limité puisse-t-il être.

Tu te dois donc d'y apporter toujours la même rigueur, même si tu estimes que "franchement, c'est vraiment pas un projet critique"

mais d'essayer de voir si on peut le faire ou non.

Hé bien, la réponse devrait etre "non"...

Simplement parce que ce que tu peux faire sur ton projet se doit de respecter les principes de développement, et que, en l'occurrence, tu te trouves face à des classes ayant sémantique d'entité et qu'un opérateur < n'a aucun sens sur ce genre de classe.

D'autant plus que, si tu as un troll et un gobelin, je dirais que, outre le nombre de point de vie, on pourrait parfaitement considérer par défaut qu'un gobelin sera d'office plus petit qu'un troll, même si, par la suite, tu te bases sur les points de vie pour classer les trolls entre eux et les gobelins entre eux (simplement à cause de l'espace qu'il prennent à l'écran)

C'est comme essayer de kill init sous Linux, ça ne sert à rien mais ça nous amuse^^

Le principe n'est pas du tout le même...

Il ne "sert à rien" d'essayer kill init sous linux, mais tu peux le faire.

Par contre, tu ne peux pas envisager de placer un opérateur < sur une classe ayant sémantique d'entité

[Neckara]

Si je devait travailler sur un TP comme je travaille sur un projet, non seulement cela me prendrait bien plus que les 2h du TP mais en plus je devrais utiliser des notions hors-programme et qu'en théorie je ne devrais pas connaitre.
Au final je passerais 90% du temps à faire le TP sur des choses complètement inutile vis à vis de l'objectif du TP.

Après niveau TP, je n'ai pas dit que je les faisais à l'arrache, ils ont des commentaires doxygen en anglais, je met presque rien dans le main, j'essaye bien de faire plusieurs classes et de ne pas faire des fonctions/méthodes trop grandes, etc.

Concernant init, théoriquement on ne peut pas le kill même en root.
Mais on y arrive en lui envoyant un segfault qui produit un résultat indéterminé pouvant soit provoquer un arrêt de la machine, soit tuer init, soit ne rien faire etc.
Donc je pense que c'est un peu plus dangereux que de mettre un opérateur < sur une classe ayant une sémantique d'entité.

Ensuite, que créature ai une sémantique d'entité, c'est hors-sujet.
Le tout c'est de voir si je peux redéfinir l'opérateur avec des pointeurs vers une classe que j'ai créé.

Par exemple, si un jour je veux compter le nombre de fois que mon programme utiliser tel ou tel opérateur sur des pointeurs pointant sur une classe C, ça peut être amusant de voir les stats.

Après c'est juste pour essayer, bidouiller voir ce que ça donne en attendant la fin du TP.