Est ce que B est une référence de A? cad si je modifie B.Available A.Available sera modifiée? (normalement oui, mais j’aimerais avoir confirmation, c’est bien pour cela qu’il existe la fonction clone).
Maintenant plus compliqué: ==, ca compare les références, ou le contenu? Je pencherais pour les références, vu que chaque objet se voit doté de la fonction .Equals… est ce que cette fonction est automatique, ou bien faut il la dériver?
Encore plus dur! Dans le cas d’un ArrayList si je fais un Add, c’est un clone ou une référence sur l’objet qui est créée?
Est ce que B est une référence de A? cad si je modifie B.Available A.Available sera modifiée? (normalement oui, mais j’aimerais avoir confirmation, c’est bien pour cela qu’il existe la fonction clone).[/quote]
B est une reference sur A. Pour avoir une clone, c’est bien la methode clone()
Encore exacte, ca compare les references. Pour le .equals, il est lance en serie sur chaque objet contenu dans ton objet donc tu n’es pas forcer de le deriver.
[quote]Encore plus dur! Dans le cas d’un ArrayList si je fais un Add, c’est un clone ou une référence sur l’objet qui est créée?
[right][post=« 347766 »]<{POST_SNAPBACK}>[/post][/right][/quote]
C’est bien sur la reference qui est dans le tableau (et heureusement!)
Pour le coup de l’arraylist, c’est pour ca que le boxing/unboxing est couteux : Elle ne prend que des objets réferrences. Du coup quand tu mets un int (un entier est un objet valeur) ou tout autre objet valeur dans une arraylist, un objet est créé pour créer une sorte de pointeur vers ton objet de base. Et quand tu le recast en int (ce qui se passe automatiquement quand tu fais une comparaison par exemple), et bien c’est l’inverse qui se passe : tu recopie la valeur référencée dans une nouvelle variable de type int.
Autre chose, par défaut le == peut être redéfinit!
C’est le cas par exemple pour le type string:
en C# tu peux avoir :
string a = « blu »;
string b = « blu »;
if(a==b )
{
// Le contenu de se bloc va s’éxécuter.
}
Attention, en Java ca n’est pas le cas!
D’ailleurs c’est un des trucs que je n’aime pas en C#, le type string… Y’a bien StringBuilder pour manipuler les chaine de caracteres dans un seul buffer, mais tous les contrôles (Web et Windows) et objets de System.Drawing ont leur propriétés / méthodes etc… qui sont en string et non en stringbuilder…
Moi j’aurais aimé pouvoir lier une propriété d’une de mes classes à celle d’un contrôle en faisant en sorte que les 2 références pointent vers le même objet…
Si des Guru du Dev veulent réagir… on peut lancer un débat
Non le fait que les string soient un type immutable permet de grandes optimisations de perfs et est beaucoup plus intuitif je trouve perso. Au contraire c’est un des points forts de C#, me likey. Le truc c’est que t’as des value type, des reference type, et des immutable type qui se comportent exactement comme des value type bien que « en theorie » ils devraient etre des reference type. Ils sont tres tres rares et les cas ou tu dois creer les tiens sont super pas courants, mais ca peut arriver, donc tu peux le faire.
Pour le type string, il est bien précisé que le == était surchargé pour faire la comparaison stricte des deux chaines.
Pour revenir aux histoires de référence :
[quote name=’[PERE]Cil’ date=’ 6 Apr 2005, 14:18’]j’ai mon objet A qui a une propriété Available.
maintenant si je fais:
A.Available = true;
B = A;
Est ce que B est une référence de A? cad si je modifie B.Available A.Available sera modifiée? (normalement oui, mais j’aimerais avoir confirmation, c’est bien pour cela qu’il existe la fonction clone).
[right][post=“347766”]<{POST_SNAPBACK}>[/post][/right][/quote]
Dans le cas d’un objet de classe, pas de probleme, c’est une référence qui est affectée.
Cependant, ce n’est pas le cas des valuetypes :
types natifs (sauf string)
structs
enums
pour lesquels l’affectation “clone” la valeur dans la variable.
