Surcharge d'opérateur

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : Surcharge d'opérateur

Taz

bisounours-codeur

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

Publicité

nraynaud

lol

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

Taz

bisounours-codeur

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.

kirua_sama

Learn sciences with senses

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”

FORUM HardWare.fr

Programmation

C#/.NET managed

Surcharge d'opérateur

Sujets relatifs
Surcharge de l'Opérateur Virgule	probleme declaration operateur new
operateur inconnu ?	surcharge de fonctions dans une dll classique, help plz
Opérateur de comparaison : vérifie si mon champ contient le mot voulu	coût operateur operation
Probleme heritage/surcharge d'operateur	Surcharge d operateur = et virtual , ca va ensemble ?
surcharge d'operateur quand en faire des fonctions membres/pas membres	[c++]surcharge d'operateur
Plus de sujets relatifs à : Surcharge d'opérateur

Page générée en 0.045 secondes