Discussion :

[Laurent Dardenne]

.NET 1.1

Bonjour,
j'aimerais savoir ce qui différencie un TYPE d'une CLASSE sous .NET si tout est considéré comme Objet ?
Est-ce la localisation de l'allocation mémoire ( Pile ou tas ) ?
Existe-t-il une régle qui détermine si l'allocation se fait sur la pile ou sur le tas ou est-ce le contexte d'utilisation ?

Merci

[Thomas Lebrun]

un type, c'est int, booleen, string, etc....

une classe, c'est un "type" personnalisé (si l'on peut dire )

[Maniak]

une classe, c'est un "type" personnalisé (si l'on peut dire :) )

On peut aussi dire que "type" regroupe tout, que "classe" est un type référence -> stocké sur le tas, et que "structure" est un type valeur -> stocké sur la pile :)

[Emerica]

Dur dur de trouver une différence concrète...

Un type est un objet, mais une instance de classe est un objet, et non la classe elle-même. L'allocation mémoire varie, comme l'a dit Maniak, selon si c'est un type de référence ou un type de valeur. Les types de valeur comme Boolean, Int32, Double (etc...) sont stockés sur la pile tandis que les types références comme Object, StreamReader ou HttpChannel sont stockés sur le tas managé (managed heap). Seule une référence vers la zone mémoire ou l'objet est stocké est mise sur la pile.

Cette image est assez parlante :


Considère que chaque rectangle du schéma est un type, avec Object comme type de base commun.

[Laurent Dardenne]

Cette image est assez parlante :

merci.
ça calme les méninges

Si j'ai bien compris le type ( value ou reference ) est figé tout au long de la vie d'une instance ?

Par contre si j'ai un struct de taille importante disons 100Ko dans ce cas le CLR/Gestionnaire mémoire utilise-t-il toujours la pile ou cela peut varier ?

[Maniak]

Si j'ai bien compris le type ( value ou reference ) est figé tout au long de la vie d'une instance ?

Yup.

Par contre si j'ai un struct de taille importante disons 100Ko dans ce cas le CLR/Gestionnaire mémoire utilise-t-il toujours la pile ou cela peut varier ?

struct -> pile. Et copie intégrale de son contenu à chaque fois qu'elle doit être passée en paramètre. Donc, les structures de grande taille sont à éviter, pour peu qu'elles aient besoin d'être passée à ne serait-ce qu'une seule méthode :)

[abelman]

... Donc, les structures de grande taille sont à éviter, pour peu qu'elles aient besoin d'être passée à ne serait-ce qu'une seule méthode

sauf si elles sont passées à ta méthode par reference et non par valeur (mot clé ref) (je complique encore tout moi)

[Laurent Dardenne]

Merci pour vos réponses, remerciements tardifs mais dû à un petit pb de notification je pense.

sauf si elles sont passées à ta méthode par reference et non par valeur (mot clé ref) (je complique encore tout moi)

Non pas du tout, au contraire.

Dans le cas où je passe un type value par référence, est-ce qu'il y a une opération de boxing/unboxing en entrée de procédure ?

[Maniak]

Dans le cas où je passe un type value par référence, est-ce qu'il y a une opération de boxing/unboxing en entrée de procédure ?

D'après tout ce que j'ai vu jusque là, non.

Mais il reste qu'utiliser ref et out doit être limité aux cas où il n'y a *vraiment* pas d'autres solutions. Et en général il y en a d'autres.

[Laurent Dardenne]

Mais il reste qu'utiliser ref et out doit être limité aux cas où il n'y a *vraiment* pas d'autres solutions. Et en général il y en a d'autres.

D'accord, mais je dois que ta derniére phrase a piquée ma curiosité :

Et en général il y en a d'autres.

...

Mais pour l'instant et pour terminer sur ce point, dans le cas où j'ai une classe C déclarant un membre A de type struct, la construction suivante C.A est elle un type value ou un type référence ?

[Maniak]

D'accord, mais je dois que ta derniére phrase a piquée ma curiosité

C'est une question de design là, ça dépend du code.

Par exemple un cas fréquent où on a tendance à vouloir passer des paramètres via ref, c'est si on a une méthode qui 'renvoit' plusieurs paramètres. Ça, ça se règle souvent en ajoutant une classe qui fait l'intermédiaire.

Si on passe une structure et qu'on veut que son contenu soit modifié en retour, on peut plutôt faire en sorte que la méthode renvoit une version modifiée de l'objet, plutôt que de passer par ref. Ou se demander si une structure est vraiment appropriée et s'il ne serait pas mieux d'en faire une classe.

C'est du cas par cas, mais de manière générale, ref et out obscurcissent le sens du code. Et c'est pas une bonne chose :)
(un cas où on n'a pas le choix, c'est pour le code qui appelle des composants COM. là, ref et out courent les rues)

Mais pour l'instant et pour terminer sur ce point, dans le cas où j'ai une classe C déclarant un membre A de type struct, la construction suivante C.A est elle un type value ou un type référence ?

Le "chemin d'accès" à un objet n'a aucune importance. C'est une structure, donc type valeur.

La distinction est vraiment basique :
structure -> valeur
classe -> référence

Y a pas à chercher plus loin pour ça.

[Laurent Dardenne]

Merci pour tes explications

Y a pas à chercher plus loin pour ça.

Je le pense aussi, je tourne la page