[C#] Déréférencer/cloner object

Citation:

---

Envoyé par moldavi

http://msdn.microsoft.com/fr-fr/libr...=VS.80%29.aspx



Donc je dirais que non le C# ne prends pas en charge le déréférencement, mais que oui par une bidouille...

---

Beh si c'est pris en charge, unsafe c'est un mot clef du langage c# non ? sauf si pour vous unsafe = bidouille mais à priori cela permet de préciser un mode particulier de sécurité et permet de programmer avec des pointeurs donc c'est possible mais faut juste préciser vouloir le faire alors qu'en c++ c'est implicite il n'y a pas besoin de préciser vouloir utiliser les pointeurs

La différence est aussi qu'en c# tu es restreint à utiliser des pointeurs sur des types primitifs il me semble..

Bonjour.

Effectivement il y a le mot clé unsafe mais il faut en plus l'option de compilation /unsafe. D'où le mot bidouille plutôt ironique.

Effectivement en C++ c'est implicite mais pas en C#, ce n'est pas dans la philosophie de ce langage, d'où le débat d'avis contradictoire que j'ai vu ici.

PS : J'essaie juste d'apporter des éléments qui clarifient le débat.

Aller un exemple de déréférencement.

Code:

---

1 2 3

var o = new object(); System.Console.WriteLine (o.ToString());

---

o.ToString() pratique un déréférencement.

Citation:

---

Envoyé par NokyDaOne

Aller un exemple de déréférencement.

Code:

---

1 2 3

var o = new object(); System.Console.WriteLine (o.ToString());

---

o.ToString() pratique un déréférencement.

---

Tu ne déférences pas car l'objet est toujours accessible à la même adresse mémoire.

En simplifiant, lorsque tu utilises ToString(), tu ne fais que mettre ton doigts sur une adresse mémoire et tu appliques une fonction de lecture et d'affichage. A aucun moment, tu ne modifies l'adresse mémoire de ta variable o.

Citation:

---

Envoyé par becket

Tu ne déférences pas car l'objet est toujours accessible à la même adresse mémoire.

En simplifiant, lorsque tu utilises ToString(), tu ne fais que mettre ton doigts sur une adresse mémoire et tu appliques une fonction de lecture et d'affichage. A aucun moment, tu ne modifies l'adresse mémoire de ta variable o.

---

C'est ce qu'on appel déférencement, me trompe-je?

Citation:

---

Envoyé par Ludo.G

C'est ce qu'on appel déférencement, me trompe-je?

---

Ha enfin quelqu'un qui connait la définition de ce mot. Merci.

Citation:

---

Envoyé par NokyDaOne

Ha enfin quelqu'un qui connait la définition de ce mot. Merci.

---

La grande différence est qu'avec un déréférencement comme en c++ tu peux appliquer l'arithmétique des pointeurs. La par exemple tu ne peux pas écrire toString()++ et je ne pense pas que si tu surcharges l'opérateur ++ cela marche aussi

Bonjour.

Il y a une différence entre le C++ natif et le .net à propos du référencement. En C++ natif on référence bien une adresse mémoire. En .net on référence un objet oui, mais c'est le Garbage Collector qui détient l'adresse mémoire de l'objet. En .net à un instant T1, l'adresse mémoire d'un objet se trouve à telle adresse, à l'instant T2, l'adresse mémoire peut avoir changer parce que le Garbage Collector en a décidé ainsi. Donc en .net pas moyen de référencer au sens C++ natif du terme, sauf à utiliser unsafe qui ne s'applique pas aux objets, mais aux types primitifs.

La nuance me semble-t-elle est énorme.

Citation:

---

Envoyé par moldavi

mais c'est le Garbage Collector qui détient l'adresse mémoire de l'objet.

---

Il ne la "détient" pas, mais il peut déplacer cet objet référencé si c'est une "moveable variables", et par la même modifié la référence.

Citation:

---

On the other hand, moveable variables reside in storage locations that are subject to relocation or disposal by the garbage collector.

---

Citation:

---

Envoyé par moldavi

En .net à un instant T1, l'adresse mémoire d'un objet se trouve à telle adresse, à l'instant T2, l'adresse mémoire peut avoir changer parce que le Garbage Collector en a décidé ainsi. Donc en .net pas moyen de référencer au sens C++ natif du terme, sauf à utiliser unsafe qui ne s'applique pas aux objets, mais aux types primitifs.

---

L'instruction fixed sert justement à empêcher le garbage collector de déplacer l'objet.
ainsi d'après la norme:

Citation:

---

In an unsafe context, the embedded-statement (§8) production permits an additional construct, the fixed statement, which is used to “fix” a moveable variable such that its address remains constant for the duration of the statement.

---

Cordialement.

Citation:

---

Envoyé par moldavi

Bonjour.

Il y a une différence entre le C++ natif et le .net à propos du référencement. En C++ natif on référence bien une adresse mémoire.

---

Une adresse mémoire virtuelle oui mais pas une adresse mémoire physique.

Donc à un instant T1 la variable peut se trouver à une adresse virtuelle pointant vers une adresse physique et à un instant T2 l'adresse virtuelle peut pointer vers une autre adresse physique. Donc en C++ tu ne travailles pas avec des adresses physiques directement mais des adresses virtuelles pour le plus souvent des cas et il en est de même avec le gc...

Citation:

---

Envoyé par nicolas.sitbon

L'instruction fixed sert justement à empêcher le garbage collector de déplacer l'objet.

---

Oui merci pour ces infos, j'ai bien compris que l'option de compilation /unsafe et quelques mots clés permettent d'avoir le même comportement qu'en C++ natif, mais seulement pour les types primitifs (int, float). Ce n'est pas dans le comportement par défaut du langage( cf message 20).

Citation:

---

Envoyé par hegros

Une adresse mémoire virtuelle oui mais pas une adresse mémoire physique.

Donc à un instant T1 la variable peut se trouver à une adresse virtuelle pointant vers une adresse physique et à un instant T2 l'adresse virtuelle peut pointer vers une autre adresse physique. Donc en C++ tu ne travailles pas avec des adresses physiques directement mais des adresses virtuelles pour le plus souvent des cas et il en est de même avec le gc...

---

Soit, si vous souhaitez parler du fonctionnement de la MMU et de la gestion de mémoire de la part de l'OS, pourquoi pas. Mais c'est complètement transparent pour les applications. Lorsque nous référençons une adresse mémoire dans un programme, que la valeur se trouve sur le disque dur, dans la mémoire virtuelle ou dans le cache processeur, ce sera toujours la même adresse mémoire dans notre programme et heureusement.

Le garbage collector gère ses objets en mémoire, c'est la raison pour laquelle par défaut, il n'y a pas de mécanisme de référencement à la sauce C++ natif. En effet le mécanisme C++ natif est basée sur les adresses mémoires. La gc lui peut modifier les adresses mémoires des objets et donc ce mécanisme de référencement devient délicat à mettre en place.