sémantique de mouvement et d'entité

Peut on avoir une classe ayant une sémantique d'entité et de mouvement ?

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Salut à tous ,
j'aimerais savoir si c'était cohérent d'avoir une classe avec une sémantique d'entité et de mouvement.Après avoir cherché sur internet j'ai trouvé plusieurs avis différents : certains sont contre car la sémantique de mouvement est peu propice à l'héritage (slicing),d'autres disent que c'est possible car on ne perd pas l'unicité de l'entité .Du coup je souhaiterais avoir vos avis sur la question :) .
Sinon passez une bonne après midi et profitez du soleil pour ceux qui sont en vacances ;) .

Édité par Octodex

+2 -0

Cette réponse a aidé l'auteur du sujet

Lu'!

Déjà pour les entités qui ne sont pas destinées à être héritées, sauf cas particuliers dus à l'implémentation, pas de raison d'interdire.

En présence d'héritage, c'est partagé. Mais globalement, je serai plus enclin à la conserver. Si on regarde le profil des fonctions qui peuvent provoquer du mouvement, on va grosso modo avoir :

1
2
3
T foo();
void foo(T t);
void foo(T&& t);

Pour les deux premières, le débutant considéra qu'il n'a pas le droit de le faire puisqu'on a sémantiquement une copie ;) . Après, on passe au cas où il commence à s'intéresser au mouvement, et là, il faut apprendre.

Si on doit faire des fonctions dans le genre de celles au dessus, soit on est en train de le faire pour notre classe de base en comportement non polymorphe, soit on est en train de le faire pour un comportement polymorphique.

Dans le premier cas, on doit s'imposer de ne pas exposer de fonctions de ce genre or du code de traitement du type et on se donne déjà pas mal de garanties. Le reste est déjà commun au passage de référence : on ne vide pas une référence reçue.

Dans le second cas, euh, à moins d'être une buse tu sais que tu es en train de violemment te tirer une balle dans le pied puisque tu sais que ça va conduire à du slicing.

Le désavantage certain de l'autoriser c'est clairement qu'on n'a plus de garanties par typage. Mais l'interdire, c'est aussi s'interdire des architectures pratiques où l'on garde les éléments dans des tableaux sans indirection et qu'on s'ajoute à côté un tableau d'indirection plus général pour les comportements polymorphes.

First : Always RTFM - "Tout devrait être rendu aussi simple que possible, mais pas plus." A.Einstein

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte