Discussion :

[Erakis]

Bonjour

Régulièrement j'implémente des classes à partir de CollectionBase. Voyons un exemple du problème :

Création de l'object à insérer dans la collection spécialisée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
UnObject unObject = new UnObject( 100 );
MaList.Add( unObject );

Modification de la propriété de object à l'intérieur de la collection

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
UnObject unObject = MaList[0];
unObject.MaValeur = 10;

À partir d'ici, si je fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
int valeur = unObject.MaValeur;

On remarque que valeur aura la valeur 100, ce qui confirme MaList[0] retourne une COPIE de l'object et NON une référence.

Est-il possible de retourner une RÉFÉRENCE à l'aide de l'indexeur this ?
Merci

[JolyLoic]

C'est étonnant. Peux-tu montrer comment tu as implémenté cette collection ? Du moins l'indexeur ?

[Sphax]

Salut,

Tu peux obtenir ce comportement si UnObjet est une structure et non une classe. En .net les structures sont de types valeurs et "subissent" un phénomene de boxing/unboxing qd tu les mets dans des collections, ce qui aurait pour effet exactement ce que tu dis (attention avec les collections generiques le comportement a changé je crois, mais je ne me suis pas encore documenté la dessus).

[neguib]

mmmh bizarre; ton type UnObject est bien une classe et non une structure ?

[Erakis]

Le type UnObject est effectivement une structure. Merci de me l'avoir fait penser Je vien tout juste d'allumer ! Eh oui c'est une STRUCTURE et du même coup c'est pourquoi je récupère une simple copie. C'est emmerdant tout de même ! En C++ j'aurais fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
UnObject & this[int index]
{
   return List[index];
}

Mais en C# je ne vois aucun moyen de travailler directement sur la référence, à moins de remplacer l'object après l'avoir modifieé.

[neguib]

Le type UnObject est effectivement une structure. Merci de me l'avoir fait penser Je vien tout juste d'allumer ! Eh oui c'est un STRUCTURE et du même coup c'est pourquoi je récupère une copie. C'est emmerdant tout de même ! En C++ j'aurais fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
UnObject & this[int index]
{
   return List[index];
}

Mais en C# je ne vois aucun moyen de travailler directement sur la référence, à moins de remplacer l'object après l'avoir modifieé.

Ben pourtant je t'ai donné la réponse transforme ton type structure en classe et voilou
Le type structure doit être moins souvent implémenter qu'on ne le croit, d'autant plus si on envisage de collectionner ces types, à mon très très humble avis.

[Erakis]

Le type était struct du fait que la taille totale des membres était minuscule. Donc côté performance c'était plus sain d'utiliser une struct qu'une classe.

Par la même occasion peut auras-tu réponse à cette question :
Lorsqu'on a un membre de type class dans la struct, quelle taille à ce membre s'il est considéré comme une référence, peut-on dire que c'est comme un pointeur 32 bits ?

[neguib]

Je ne pense pas être assez bon pour te répondre correctement sur le dernier point, cependant je suis très surpris de l'importance que tu accordes au critère de taille comme pesant à ce point sur les performances d'une class . Regardes cet article, tu trouveras peut être des considérations interressantes plus globales en terme de coût/performances.

[abelman]

Salut (comme on se retrouve ;-))

A moins d'utiliser le mode unsafe on ne peut pas.
En unsafe tu peux manipuler les pointeurs. Les références 'C++' non. .
Voici comment faire par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public struct test
{
	int i;
}
 
unsafe static public test* RetourneStructRef()
{
	test atest = new test();
	return &atest;
}
 
 
unsafe static void Main(string[] args)
{
	test* pt = RetourneStructRef();
 
}

Pour que ça compile, tu dois avoir 'autoriser les blocks de code unsafe' à true dans les propriétés du projet (Dans 'Générer'). Par je ne connais pas le code unsafe. documente toi bien avant de te lancer là dedans.

[abelman]

Je ne pense pas être assez bon pour te répondre correctement sur le dernier point, cependant je suis très surpris de l'importance que tu accordes au critère de taille comme pesant à ce point sur les performances d'une class . Regardes cet article, tu trouveras peut être des considérations interressantes plus globales en terme de coût/performances.

Lequel cher collègue ???

[neguib]

Lequel cher collègue ???

là c'est sûr je fatigue voici le lien manquant : http://www.jaggersoft.com/pubs/StructsVsClasses.htm

[Erakis]

Si l'on se base sur ce que tu m'as dit tantôt à propos d'un nombre élevé de connections alors la liste contenant mes objects sera aussi quant à elle énorme. Je ne me rappel plus ou j'ai lu cela mais en terme de performance il est préférable d'utiliser un structs si la taille totale (déclaration de l'object) ne dépasse pas les x bytes. Le hic, c'est que je ne me rappel pas la taille de x

[abelman]

la taille de 'x' comme tu dis c'est 16 bytes d'après 'Programming Micorsoft Visual Basic 2005 the language' de FRansceco Balena.

[Erakis]

la taille de 'x' comme tu dis c'est 16 bytes d'après 'Programming Micorsoft Visual Basic 2005 the language' de FRansceco Balena.

Merci !!!
Donc je vais convertir le tout en class puisque mon object dépasse largement les 16 bytes.

Cependant dans l'exemple suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
public class ThreadObject
{
    private int ClientID;           // 32 bits
    private Socket ClientSocket;    // ???
    private Thread ClientThread;    // ???
}

Comme les deux derniers membres sont des référence sur un object, quelle est la taille pris dans la classe ? 32bits ou la taille réelle de l'objet ?

Merci.

[abelman]

Merci !!!

Comme les deux derniers membres sont des référence sur un object, quelle est la taille pris dans la classe ? 32bits ou la taille réelle de l'objet ?

Merci.

32 bits evidement

[Erakis]

Un gros merci.
Je crois bien qu'on a fait le tour de la question

[JolyLoic]

la taille de 'x' comme tu dis c'est 16 bytes d'après 'Programming Micorsoft Visual Basic 2005 the language' de FRansceco Balena.

Oups, j'avais commencé à dire des bêtises... J'avais lu bits et non pas bytes dans ton message...

En terme de performances, la différence se situe selon moi principalement sur les points suivants :
- 2 pointeurs en mémoire pour chaque référence, soit 64 bits, et donc un overhead non négligeable pour chaque variable.
- Une allocation mémoire dynamique, certe avec un pool mémoire, mais quand même, par rapport à passer ça sur une pile ou dans des registres, il y a un écart.
- Le fait de devoir garbage collecter, ce qui s'il y a plein d'objets peut être non négligeable. Ne pas oublier l'exemple admis par Microsoft d'un serveur qui passait 70% de son temps dans le GC.

Mais a mon avis, le plus important n'est pas là. Il y a des objets qui ont une sémantique de valeur, d'autres une sémantique de référence, (et d'autres autre chose encore) et c'est ce qui devrait avant tout guider le choix. Ici, on ne voulait pas une sémentique de valeur, donc utiliser une struct était une erreur.

[Erakis]

Merci beaucoup JolyLoic d'avoir pris le temps de revenir éguiser la solution