|
|
 Up |
  |
Author: Mickaël WolffMickaël Wolff Date: Apr 29, 2008 17:59
Bonjour,
Si on a les trois classes suivantes :
class A
{
public:
virtual A & operator=(A const & rvalue) ;
/* ... */
} ;
class B0 : public A
{
public:
virtual A & operator=(B0 const & rvalue) ;
/* ... */
} ;
|
| Show full article (1.04Kb) |
| 8 Comments |
|
|
Author: Sylvain SFSylvain SF Date: Apr 29, 2008 18:31
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 (b0) ; ...
|
| Show full article (1.56Kb) |
| no comments |
|
|
Author: James KanzeJames Kanze Date: Apr 30, 2008 01:06
On Apr 30, 2:59 am, Mickaël Wolff laposte.net> wrote:
> Si on a les trois classes suivantes :
> class A
> {
> public:
> virtual A & operator=(A const & rvalue) ;
> /* ... */
> } ;
> class B0 : public A
> {
> public:
> virtual A & operator=(B0 const & rvalue) ;
> /* ... */
> } ;
|
| Show full article (6.69Kb) |
| no comments |
|
|
Author: Mickaël WolffMickaël Wolff Date: Apr 30, 2008 05:14
Sylvain SF a écrit :
> elle set impossible comme telle.
> B1 définit un operateur = avec B1& en paramètre, pas un A&
En fait si. En fait, B0::operator=(B0 const &) empêche la création
d'un operator= automatique. Un effet de bord est donc l'appel de
A::operator=(A const &) à l'affectation d'un A. C'est du moins le
comportement que j'observe avec gcc 4.3.0, et il ne me parait pas aberrant.
>> 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.
Effectivement, c'est une solution à envisager.
> 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::operator= (B1 const&) (et vice-versa).
Merci pour ta réponse.
|
| Show full article (1.20Kb) |
| no comments |
|
|
Author: James KanzeJames Kanze Date: May 2, 2008 00:41
On Apr 30, 2:14 pm, Mickaël Wolff laposte.net> wrote:> Sylvain SF a écrit :
>> elle set impossible comme telle. B1 définit un operateur =
>> avec B1& en paramètre, pas un A&
> En fait si. En fait, B0::operator=(B0 const &) empêche la
> création d'un operator= automatique. Un effet de bord est donc
> l'appel de A::operator=(A const &) à l'affectation d'un A.
> C'est du moins le comportement que j'observe avec gcc 4.3.0,
> et il ne me parait pas aberrant.
En fait, non. Tu ne trouves l'operator=( A const& ) que parce
que tu affectes à travers un A. Rappelons comment se passe les
choses :
-- Le compilateur recherche le nom (ici, operator=). Dans le
cas d'un opérateur, cette recherche est un peu spéciale,
parce qu'il considère à la fois des fonctions libres et des
fonctions...
|
| Show full article (3.12Kb) |
| no comments |
|
|
Author: Mickaël WolffMickaël Wolff Date: May 6, 2008 17:02
James Kanze a écrit :
> Dans la pratique, tu dois te démander si ça a un sens. Au moins
> dans les applications que je fais, le polymorphisme s'applique
> surtout à des objets ayant une identité, et donc, qui ne
> supporte ni l'affectation ni la copie.
Qu'est-ce que tu appelles une identité ?
> class B0 : public A {
> {
> public:
> virtual B0& operator=( A const& other ) ;
> // ...
> } ;
Oui, en fait j'ai mal posé mes exemples. Finalement, dans le cas où
j'avais besoin d'affectations et de comparaisons virtuelles pour me
libérer de la nature des objets.
> (Que l'opérateur renvoie un B0& ou un A&, en revanche, n'a pas
> d'importance, puisque le C++ supporte les types de retour
> co-variants.)
Ça j'avais compris :)
|
| Show full article (3.60Kb) |
| no comments |
|
|
Author: James KanzeJames Kanze Date: May 7, 2008 01:02
On May 7, 2:02 am, Mickaël Wolff laposte.net> wrote:> James Kanze a écrit :
>> Dans la pratique, tu dois te démander si ça a un sens. Au moins
>> dans les applications que je fais, le polymorphisme s'applique
>> surtout à des objets ayant une identité, et donc, qui ne
>> supporte ni l'affectation ni la copie.
> Qu'est-ce que tu appelles une identité ?
C'est qu'une opération sur un objet n'en vaut pas la même
opération sur un autre, même si la « valeur » est la même.
L'exemple typique (mais bien simplifié), c'est un compte en
banque, et une valeur qu'on y vire ou prélève. Le compte a une
identité ; faire la virement sur une copie de l'objet, ou un
autre objet qui a par hazard la même valeur ne va pas. La valeur
qu'on y vire ou prélève, en revanche, n'a pas d'identité : 100
Euros, c'est 100 Euros, que ce soit une copie ou non.
|
| Show full article (6.32Kb) |
| no comments |
|
|
Author: Alexandre AbreuAlexandre Abreu Date: May 8, 2008 08:26
On May 7, 4:02 am, James Kanze gmail.com> wrote:>
> En gros, la dérivée ne doit pas
> imposer des préconditions plus contraignantes, et doit garantir
> des postconditions au moins aussi fortes que la base.
Je ne veux pas "hijacker" le sujet mais juste une remarque a propos de
cette affirmation.
C'est qquechose qu'on entend souvent et qui est dit et repete quand on
parle de contrat / interface
et qu'on evoque differentes implementations de ce contrat dans le
temps.
|
| Show full article (1.34Kb) |
| no comments |
|
|
Author: James KanzeJames Kanze Date: May 9, 2008 00:51
On May 8, 5:26 pm, Alexandre Abreu gmail.com> wrote:> On May 7, 4:02 am, James Kanze gmail.com> wrote:>> En gros, la dérivée ne doit pas imposer des préconditions
>> plus contraignantes, et doit garantir des postconditions au
>> moins aussi fortes que la base.
> Je ne veux pas "hijacker" le sujet mais juste une remarque a
> propos de cette affirmation. C'est qquechose qu'on entend
> souvent et qui est dit et repete quand on parle de contrat /
> interface et qu'on evoque differentes implementations de ce
> contrat dans le temps.
> Par contre, c'est quelquechose qui m'a toujours plus ou moins
> derange (bien que je l'utilise de cette facon) car j'ai
> l'impression que tolerer des preconditions moins
> contraignantes et / ou des postconditions plus contraignantes
> brise le contrat d'une certaine facon. Je n'ai jamais encore
> pu accepter cette affirmation de but en blanc, peut etre parce
> qu'il me manque un element, je ne sais pas ...
Je suis en fait un peu de cet avis moi-même, que faire des
préconditions plus libérales ou des postconditions plus strictes
n'est pas vraiment dans le sens de la chose, au moins quand on
parle de l'aspect...
|
| Show full article (3.48Kb) |
| no comments |
|
|
