Surcharge d'opérateur

Marsh Posté le 05-08-2004 à 00:12:21

je suis entrain de voir comment on fait de la surcharge d'opérateur de manière bien carrée, et j'en arrive à des conclusions bizarres. arrêtez moi si je me trompe.

déjà, myInstance == null, ne va pas conduire au cast myInstance en object et donc vérifier si myInstance __est__ null, mais va appeler operator==(myInstance, null) et risque donc de balancer une exception. Pas terrible, il va falloir sécuriser ça. Ça me permet de déduire que la seule manière de savoir si deux références pointent sur le même objet est '(object)a == (object)b' ... bof, on aurait pu utiliser le mot-clef is, plutot que d'avoir 3 opérateurs de cast. bref.

je me demande dans quelle mesure on doit s'occuper de ces histoires de null. Déjà, je pars dans l'idée habituelle de définir == et != en fonction de .Equals(object).

Code :

public class Foo
{
int i = 0;
public Foo(int j)
{
this.i = j;
}
public override int GetHashCode()
{
return this.i;
}
public bool Equals(Foo other)
{
if((object)other == null)
return false;
return this.i == other.i;
}
public override bool Equals(object o)
{
return this.Equals(o as Foo);
}
public static bool operator==(Foo left, Foo right)
{
if((object)left == null)
{
return (object)right == null;
}
return left.Equals(right);
}
public static bool operator!=(Foo left, Foo right)
{
return ! (left == right);
}
}

vous en pensez quoi ? Harko ?
est le coup du != pas automatiquement généré, c'est Mono ou c'est fait expres ? j'ai essayé de minimiser pour avoir quelque chose d'orthogonal et de sur. un avis ? est-ce que c'est la philosophie du truc ou je devrais carrément ne pas me soucier des null ? est que == a une sémantique plus large que a.Equals(b) auquel cas il faut gérer les null (du moins pour a) ? est-ce que mon code va à contre sens de certaines pratiques et peut donc amener à un comportement différent de ce qui se fait ?

Merci

Message édité par Taz le 05-08-2004 à 01:02:04

Reply

Marsh Posté le 05-08-2004 à 00:12:21

Reply

Marsh Posté le 05-08-2004 à 00:34:50

Taz a écrit :

Déjà, je pars dans l'idée habituelle de définir == et != en fonction de .Equals(object).

à l'intuite, je dirait que == ça serait bien qu'il soit symétrique et réflexif et .Equals() n'est intrinsèquement aucun des 2. C'est pour ça que Eiffel fait de l'égalité un truc statique à 2 arguments.

La flemme d'aller me taper la spec ecma à cette heure pour aller vérifier les sémantiques exactes.

---------------
trainoo.com, c'est fini

Reply

Marsh Posté le 05-08-2004 à 01:01:36

je suis d'accord avec toi. seulement l'ecma veut .Equals() et ==.

donc je suis d'avis d'avoir

public override bool Equals(object o)
public bool Equals(Foo other)

le premier castant avant d'appeler l'autre. .Equals() gère le cas ou other est null.

et ensuite == et !=, qui gèrent leurs arguments null. a == b -> si a != null, a.Equals(b), sinon voir si b lui aussi est nul.

par contre, je tremble un peu, je regarde les bouquins d'oreilly, y aucune vérification de null, et on sort des grand coup de o.GetType() plutôt que de caster.

Reply

Marsh Posté le 19-08-2010 à 09:46:12

http://msdn.microsoft.com/fr-fr/li [...] 80%29.aspx

---------------
“L'éducation est l'arme la plus puissante que l'on puisse utiliser pour changer le monde”

Reply

Surcharge d'opérateur

Sujets relatifs:

Leave a Replay