[VB.NET]Comment s'opère la copie profonde d'objet?

Bonjour à tous,
Je me pose qqes questions de base sur les pointeurs sous jacents au fonctionnement des copies et transferts d'objets.

1) Lorsque l'on fait

Code:

---

1 2 3

Dim mavar as new Object dim mavar2 as new Object mavar = mavar2

---

Le premier objet et le deuxième sont devenus le même, ce sont les références que l'on a copié et non l'objet directement?! Tout modification de mavar modifiera également mavar2 et inversément?!
2) Lorsque l'on passe un objet en paramètre avec le mot clé byval, il y a copie de l'objet?! Si cet objet comprend lui même un objet, qu'advient-il de cet objet? Il est copié également, ou c'est juste une référence qui pointe sur le même objet que celui passé en paramètre?
3) (Relatif à la question précédente)Lors d'un appel du constructeur de copie, si la classe comprend un objet, dois-je manuellement faire une copie de cet objet dans le constructeur? Si oui, même dans le cas ou mon objet passé au constructeur de copie est passé ByVal?
4) Est-ce que

Code:

---

1 2 3

Dim mavar as New Object Dim mavar2 as Object dim mavar3 as Objetct = Nothing

---

Sont toutes les 3 des références ou le premier est un objet?

Merci d'avance :)
Nicolas

En .NET, en général, ce qui hérite de System.Object est passé par référence et ce qui hérite de System.Type est passé par valeur.


1) Dans ton premier exemple tu as une "fuite mémoire". Tu crées un objet pour mavar, ensuite tu crées un objet pour mavar2, et tu dis que mavar et mavar2 ont la même référence. Donc l'objet initialement créé sur mavar n'a plus de référence.

2 )Pour la question du ByVal, je ne sais pas comment il réagit. Toutefois je serai surpris que de lui même il soit capable de le faire (du moins dans le cas où tous les éléments sont sérialisables pourquoi pas, mais si un d'eux n'en est pas je vois mal comment il peut faire : peut être que l'objet doit être ISerializable) : mais rien de sûr sur ce sujet.

3) Dans le cas où tu fais la copie ton même que tu le passes par valeur n'a pas grand intérêt si ce n'est dans un contexte multithreadé où ton objet peut évoluer pendant la copie si c'est une ressource partagée.

4) mavar est une référence sur un objet. mavar2 n'est rien, juste une déclaration. mavar3 est la même chose que mavar2 sauf que tu spécifie "= Nothing" ce qui est plus lisible, mais je ne crois pas que ce soit nécessaire.


En espérant que ça t'éclaire un peu plus.

Citation:

---

1) Dans ton premier exemple tu as une "fuite mémoire". Tu crées un objet pour mavar, ensuite tu crées un objet pour mavar2, et tu dis que mavar et mavar2 ont la même référence. Donc l'objet initialement créé sur mavar n'a plus de référence.

---

Il n'y a pas réellement fuite de mémoire, le ramasse miette s'occupera de l'objet mavar, non?!

Citation:

---

2 )Pour la question du ByVal, je ne sais pas comment il réagit. Toutefois je serai surpris que de lui même il soit capable de le faire (du moins dans le cas où tous les éléments sont sérialisables pourquoi pas, mais si un d'eux n'en est pas je vois mal comment il peut faire : peut être que l'objet doit être ISerializable) : mais rien de sûr sur ce sujet.

---

J'ai fait des tests depuis et que ce soit byval ou byref, une variable membre qui n'est pas un type de base n'est pas copiée 'entièrement', c'est juste sa référence qui est copiée. C'est d'ailleurs très vache comme erreur je trouve. Malgré que le VB encapsule toute la 'difficulté' des pointeurs, il faut constemment avoir les méchanismes en tête...

Citation:

---

3) Dans le cas où tu fais la copie ton même que tu le passes par valeur n'a pas grand intérêt si ce n'est dans un contexte multithreadé où ton objet peut évoluer pendant la copie si c'est une ressource partagée.

---

Juste

Citation:

---

4) mavar est une référence sur un objet. mavar2 n'est rien, juste une déclaration. mavar3 est la même chose que mavar2 sauf que tu spécifie "= Nothing" ce qui est plus lisible, mais je ne crois pas que ce soit nécessaire.

---

En fait je posais la question car le compilo/InteliSense avait l'air de me prévenir d'une erreur si je faisais

Code:

---

1 2	Dim mavar as Object If mavar Is Nothing Then...

---

Mais il ne disait rien si je faisais

Code:

---

1 2	Dim mavar as Object = Nothing ...

---

Je pensais que = Nothing était implicite mais peut-être que ce n'est pas le cas :?

Citation:

---

En espérant que ça t'éclaire un peu plus.

---

Même beaucoup, un grand merci :)

Citation:

---

Envoyé par NicolasJolet

Il n'y a pas réellement fuite de mémoire, le ramasse miette s'occupera de l'objet mavar, non?!

---

Yup.

Citation:

---

Envoyé par NicolasJolet

c'est juste sa référence qui est copiée.

---

Yup.

Citation:

---

Envoyé par NicolasJolet

C'est d'ailleurs très vache comme erreur je trouve. Malgré que le VB encapsule toute la 'difficulté' des pointeurs, il faut constemment avoir les méchanismes en tête...

---

Y a rien d'anormal au fonctionnement. Tu passes un objet en paramètre, il est copié par valeur. Si l'objet est une référence à un autre objet (ce qui est le cas pour toutes les classes), c'est la référence qui est copiée. Pas l'objet sur lequel elle pointe.

Si tu passes une structure par contre, là c'est vraiment le contenu qui est copié.

Citation:

---

Envoyé par NicolasJolet

En fait je posais la question car le compilo/InteliSense avait l'air de me prévenir d'une erreur si je faisais

Code:

---

1 2	Dim mavar as Object If mavar Is Nothing Then...

---

Mais il ne disait rien si je faisais

Code:

---

1 2	Dim mavar as Object = Nothing ...

---

Je pensais que = Nothing était implicite mais peut-être que ce n'est pas le cas :?

---

Le compilo sort un warning si tu utilises une variable avant d'y affecter une valeur, même si la valeur en question est null.
Dans le cas de null c'est pas le warning le plus vital qui existe, mais ça t'oblige à indiquer clairement que tu veux que la valeur par défaut soit null, et que tu n'as pas oublié une initialisation quelque part. Pas plus mal.

Citation:

---

Le compilo sort un warning si tu utilises une variable avant d'y affecter une valeur, même si la valeur en question est null.
Dans le cas de null c'est pas le warning le plus vital qui existe, mais ça t'oblige à indiquer clairement que tu veux que la valeur par défaut soit null, et que tu n'as pas oublié une initialisation quelque part. Pas plus mal.

---

C'est vrai que je n'avais pas pensé au fait que ca oblige à indiquer clairement que l'on veut travailler avec "Nothing" même s'il initialise implicitement la référence à cette "valeur".

Merci à tous pour vos éclaircissements :9

Pour le coup de la fuite mémoire, oui le GC doit la supprimer. Toutefois je déconseille vivement ce genre de technique. Si un jour vous avez à utiliser des composants COM ou interoper avec du C++, ce genre de manip peut très vite provoquer un memory leak.