Afficher un message
Vieux 30/04/2008, 02h31   #2
Sylvain SF
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: Gestion de l'assignation consanguine

Mickaël Wolff wrote on 30/04/2008 02:59:
>
> class A {
> public:
> virtual A & operator=(A const & rvalue) ;
> } ;
>
> class B0 : public A {
> public:
> virtual A & operator=(B0 const & rvalue) ;
> } ;
>
> class B1 : public A {
> public:
> virtual A & operator=(B1 const & rvalue) ;
> } ;
>
> B0 b0 ;
> B1 b1 ;
> A & b0_a = static_cast<A &>(b0) ;
> b1 = b0_a ;
>
> Dans la pratique, comment devrais-je gérer une telle affectation ?


elle set impossible comme telle.
B1 définit un operateur = avec B1& en paramètre, pas un A&

> Lever une exception car c'est un non sens ? Et surtout, comment je le
> détecte dans l'affectation ?


si l'affectation est un non-sens, les operéateurs d'affectation
devraient être privés pour éviter ces non-sens.

> La solution la plus directe que je vois dans le cas où on gère
> est un dynamic_cast dans B0:perator=(A const &).


si en effet initialiser un B1 depuis un A a un sens (affectation des
attributs de base et déduction et/ou choix par défaut pour les membres
propres à B1) cet opérateur sur B0 et/ou B1 est requis.

> J'avoue que je serais partisan de rendre l'opération silencieuse,
> mais je risque de me surprendre, en perdant des information lors
> d'affectations.


si la perte signifie que l'instance sera caduque, interdissez les
affectations; si les classes sont transposables (A = coordonnées,
B0 = cartesiennes, B1 = polaires) offrez ces opérateurs et pourquoi
pas un B0:perator= (B1 const&) (et vice-versa).

Sylvain.
  Réponse avec citation
 
Page generated in 0,04834 seconds with 9 queries