Citation:
Envoyé par
gbdivers
Hum, au final, la question revient donc à savoir l'intérêt d'une classe Point3D. J'ai l'impression que l'on n'est pas d'accord sur ce point.
Non, je pense que tu pretes plus de sémantique que nécessaire au type lui même. C'est un type de stockage de donnée, ni plus ni moins, et lui donner plus de fonctionalité que l'accès et le stockage a ces données c'est exactement le meme probleme que de designer un type qui a plusieurs roles.
Citation:
On est d'accord qu'un développeur expérimenté se contentera sûrement de créer un type POD et travailler directement avec, sans s'occuper de la sémantique (ou plus précisément, l'expérience fera qu'il saura quelle est la sémantique et ne pas utiliser n'importe comment ses données).
Non, non, non non non et encore non. Ce n'est pas le sujet. :aie:
Le dévelopeur experimenté va donner un role précis a un type précis.
Le type dont on parle ici n'a qu'un role de stockage comme je le disais. Ajouter plus ou enlever à une interface d'accès et de stockage pour ce type ne fait que le rendre difficile à utiliser.
Cela ne veut pas dire qu'on ne peut pas construire d'autres type a partir de celui ci, pour donner une sémantique plus précise, comme lorsque l'on définis un type qui stock des objets et qui est composé de conteneurs.
Citation:
Le problème d'un type POD, c'est que l'on dit en gros "faites ce que vous voulez avec". Et donc potentiellement, n'importe quoi.
Tu peux faire ce que tu veux avec les données contenues dans un vector. Le type vector est la pour le stockage avec une structure memoriel bien définie.
C'est exactement pareil avec un vecteur/point 3D ou avec un entier, ou encore avec un flotant (qui a une structure bien particulière).
Le fait qu'un type est un POD dis juste qu'il n'y a pas de contrainte associée en terme de manipulation, ce qui est exactement ce que l'on veut avec un type aussi simple que celui dont on parle.
Dés le moment ou il y a une contrainte, il est de bon ton de ne pas en faire un POD.
Même pair est un pod, c'est pas pour rien! Son role n'est pas plus compliqué que de stocker deux valeurs associées. Le role du point 3D est de stocker 3 valeurs associées qui sont des nombres.
Tout le reste c'est à un niveau d'abstraction supérieur.
La différence est certes subtile, mais c'est justement cette subtilité qui rends l'article caduque: le type en exemple devrais être un POD ou un équivalent avec accès et stockage et rien d'autre. L'exemple de Bousk est globalement ce que je souleve: le but du type ici n'est pas d'etre associé a une notion d'affichage, ce sont des donnée utilisées pour l'affichage, certainement entre autre, et la donnée n'est pas censé savoir a quoi elle sert.
C'est finalement rare d'avoir a définir de tels types, mais c'est pourtant nécessaire.
Citation:
Or, le dev qui créer ce type POD le fait dans un contexte particulier, pour un usage qu'il a lui même définit. Cette utilisation présente forcement des contraintes (par exemple dans notre cas de Point3D, il ne faut pas que les coordonnées soient de NaN ou Inf).
Cela n'est pas toujours vrai, en particulier pour ce genre de type. Dans le cas d'une application particulière, redéfinir un type qui encapsule un vecteur3D est une meilleure idée.
Encore une fois, le choix du type embrouille le sens de l'article.
Citation:
Avoir une classe non POD, avec une sémantique spécifique, permet de cadrer l'utilisation de cet type et garantir que l'on ne puisse l'utiliser que comme le dev le souhaite (interdire un point dont les coordonnées ne sont pas valide).
Toutes les règles ne s'appliquent pas à tous les cas. C'est ce que j'essaie d'expliqué: tu as choisis un cas "exceptionel"...
Citation:
La sémantique n'est qu'un moyen permettant au dev de garantir que sa classe sera utilisée d'une certaine manière et pas d'une autre (pour les autres, mais également pour éviter de faire lui même une erreur par distraction)
Donc, oui, on peut faire un POD (et on verra souvent ça). Mais on se prive alors d'un moyen de sécuriser l'utilisation de la classe
Dans le cas que tu décris dans l'article, il est plus interessant de faire un pod puis un type particulier qui ajouter une couche de sémantique.
Citation:
Sauf que j'ai déjà lu, pour les mêmes raisons qui justifient de créer une classe Point3D, que l'on pouvait créer des typedef pour préciser l'unité de mesure d'un type. Par exemple :
Code:
1 2 3 4 5
| typedef float metres;
typedef float secondes;
metres longueur_piscine, largeur_piscine;
secondes temps_nageur; |
(mais je ne sais plus où j'ai lu ça, peut être dans Abrahms ou dans un draft sur les user-literals)
Un code utilisant des typedef précisant localement le contexte et des classes non POD verrouillant l'utilisation faites des données seront plus sur que de simple float[3]
Ce cas est un gros piège et risque de détourner la discussion, mais je t'invite a voir std::chrono pour réaliser qu'au final ce n'est pas une bonne idée de faire cela avec des typedefs, meme si c'est suffisant pour une implémentatoin "simple" dont la sémantique n'a pas grand effet sur l'application.