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.

[gbdivers]

Je rejoint koala01

C'est la sémantique qui va te permettre de choisir les solutions techniques adaptées. Sans sémantique claire, tu vas rechercher des solutions techniques bancales, voir te retrouver dans une impasse technique (ce qui te conduira à forcer l'utilisation d'une solution technique encore plus bancale au lieu de revoir ta sémantique)

Tu as suffisamment d'expérience pour savoir que beaucoup de questions techniques posées par les débutants viennent du fait qu'ils ont choisit une conception bancale, qui nécessite des solutions techniques encore plus bancale et qu'ils sont incapables de remettre leurs conceptions en question

[Neckara]

Je sais mais là c'est un TP, je ne suis pas censé savoir ce qu'est une sémantique tout comme je ne suis pas censé savoir utilisé les thread ou les templates.

C'est comme quand dans les TP je ne programme pas de manière portable, vu que j'utilise des sockets Unix (imposé par le TP).

Mais si la classe Creature vous pose problème, je la remplace par une classe NombreComplexe et la problématique initiale est toujours la même.

Le but était de redéfinir un opérateur avec des pointeurs sur une classe, la classe Creature était plus un prétexte qu'autre chose.

[screetch]

le probleme est different; pourquoi aurais tu un pointeur sur un NombreComplexe qui a une semantique de valeur et devrait donc etre copié?
c'est juste que tu n'as pas compris la difference entre entité et valeur.

[Neckara]

le probleme est different; pourquoi aurais tu un pointeur sur un NombreComplexe qui a une semantique de valeur et devrait donc etre copié?
c'est juste que tu n'as pas compris la difference entre entité et valeur.

On peut dire que ma classe NombreComplexe est super grande car je manipule des tableaux de long long int pour la partie imaginaire et donc que la copie est très coûteuse.
Et qu'en plus je dois faire beaucoup de copie si je n'utilise pas de pointeurs et que mon programme est déjà très long à l'exécution en temps normal.

[screetch]

c'est pour ca que Dieu a inventé les references. Les pointeurs c'est pour les entités.

std::vector manipule des tableuax d'objets et pourtant a une semantique de valeur.

[Neckara]

c'est pour ca que Dieu a inventé les references. Les pointeurs c'est pour les entités.

std::vector manipule des tableuax d'objets et pourtant a une semantique de valeur.

Et tu fais comment pour mettre un NombreComplexe par référence dans une liste ou un vecteur ?
D'après ce que tu dis ici ce n'est pas possible car :

il n'y a pas d'opérateur d'affectation pour les références.

Donc soit tu copie mais c'est extrêmement lourd, soit tu utilises des pointeurs.

[screetch]

Non, on utilise pas de pointeur dur des valeurs, on utilise des pointeurs sur des entites. On ne compare pas des entites, on compare des valeurs, c'est vraiment comme ca qu'on fait dans du code propre, meme si c'est lourd a copier.

les exemples que tu prends sont toujours tires par les cheveux, mais le concept de base reste le meme, les entites ne sont pas "ordonnables", ca n'a pas de sens.

Je recommande de lire:
http://blog.emmanueldeloget.com/inde...C3%A9placement

[koala01]

On peut dire que ma classe NombreComplexe est super grande car je manipule des tableaux de long long int pour la partie imaginaire et donc que la copie est très coûteuse.
Et qu'en plus je dois faire beaucoup de copie si je n'utilise pas de pointeurs et que mon programme est déjà très long à l'exécution en temps normal.

Même si tu décides, pour une raison ou une autre, de maintenir un ensemble de pointeur sur une classe ayant sémantique de valeur, tu compareras toujours... ce qui se trouve à l'adresse représentée par le pointeur et non le pointeur en lui-même...

Ton code sera donc, au pire, toujours plus proche de

Code :

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

if ( *tab[X] < *tab[Y] )

que d'autre chose

[koala01]

Je sais mais là c'est un TP, je ne suis pas censé savoir ce qu'est une sémantique tout comme je ne suis pas censé savoir utilisé les thread ou les templates.

C'est comme quand dans les TP je ne programme pas de manière portable, vu que j'utilise des sockets Unix (imposé par le TP).

Ne pas coder portable ou utiliser les sockets Unix parce que c'est imposé est une chose.

Mais ce sont des choix d'implémentation uniquement!

Par contre, le choix de vouloir mettre un opérateur < sur une classe ayant clairement sémantique d'entité est un choix de conception pure, et là, les règles de conception s'y opposent bien avant d'écrire la première ligne de code (et d'autant plus si le code est déjà écrit et fait sans )

[Neckara]

Le but était plus d'arriver à redéfinir l'opérateur que d'arriver à un résultat.

C'est comme faire 2 fork juste pour afficher un "Hello world" via les deux fils après un signal du père.
Niveau conception c'est assez horrible mais cela a une utilité pédagogique.

Après on ne peut pas exiger d'un étudiant de 2ème année de coder aussi proprement que des personnes qui ont plusieurs années d'expérience comme certains d'entre-vous.
En soit j'ai encore beaucoup à faire pour produire un code plus propre par exemple je n'utilise pas assez ce qui a déjà été fait dans boost ( d'ailleurs je ne serais pas en IUT si je n'avais plus rien à apprendre ) mais j'apprends petit à petit.
Pour la non-comparaison d'entités, je veux bien mais dans un TP de 2h qui ne sera jamais réutilisé et où je veux juste essayer de voir si redéfinir un opérateur prenant des pointeurs est possible, je pense pouvoir m'autoriser quelques libertés.

Après est-ce qu'on peut trouver une utilité?
Peut-être, par exemple si on veut interdire le déférencement sous certaines conditions d'un pointeur sur une classe C (pour éviter des segfault par exemple).
Si on veut faire des statistiques pour compter le nombre d'opérateurs appelés lors d'une exécution de son programme.
On doit pouvoir trouver 2/3 choses amusantes à faire si c'était possible^^

[Invité]

bonjour,

je n'apporterai pas de solution dans l'immédiat, j'ai pas lu l'autre fil, mais je suis complètement d'accord avec Neckara sur le fait qu'on peut s'en foutre complètement de savoir si la solution est bancale ou pas, il me semble qu'il s'agit d'un détail technique.

Est-ce possible? si oui comment?

Si ca ne doit pas être fait pour un TP -qui est une chose- ca n'empêche en rien de se poser la question. Ca peut paraitre stupide tellement c'est gros, il n'empêche que ca peut en valoir l'intérêt.

Je rapproche ca au fait de vouloir expliciter le terme général d'une suite alors qu'on a la récurrence. Pour certains cas ca sert à rien, ca n'empêche pas de vouloir essayer.