Copie PHYSIQUE de Liste

Bonjour

Je suis a nouveau confronté a un problème tres casse pipe :aie:

Je dispose d'une List<T> de classes CT
Je souhaite construire un array de classe CT a partir de cette Liste mais les éléments de mon array doivent etre totalement indépendant de ma liste de base

J'ai essayé le

Code:

---

1 2 3

List.ToArray; //ou le Array.Copy(List.ToArray, etc)

---

Rien n'y fait !!

C'est le coup qui me fait regreter les pointeurs en C, au moins on savait ce qu'on faisait de maniere Explicite !

beh alors peut-etre fournir un constructeur de copy ou une fonction de clonage avec le MemberwiseClone() ?

C'est la misere totale ce truc !!
J'ai tout essayé
La doc MemberwiseClone() dit bien qu'il s'agit AUUSI d'une copie superficielle

En fait si je comprends bien une List ou ne contient que des references a des objets et il n'est pas possible de creer une nouville liste de nouveaux objets

Il faut donc vraiment recreer les objets un a un et constituer une nouvelle liste ou un array de toute pieces

Ici je regrette vraiment la souplesse des pointeurs et memmove en C

Tu peux modifier ta classe pour qu'elle implémente ICloneable...

oui on peut raler mais en programmation objet, ce que tu souhaites faire s'appuie sur le constructeur par copie...

Du genre :

Code:

---

1 2 3 4 5 6

class toto { public toto(toto) {...}; }

---

Donc, je ne suis pas choqué que cela se produise en C# egalement et que tu sois obligé de le faire :)..

Désolé mais ca parait assez logique comme comportement !!!

D'ailleurs, prends comme exemple la classe Region... du framework, elle implémente la méthode Clone()....

Merci TheMonz
C'est la solution que j'ai prise pour le moment

Merci TomLev

Ta solution est certainement aussi bonne m'est elle m'inquiète un peu plus car en admettant qu'on finisse a s'habituer a ce comportement par reference implementer Iclonable va, si je ne me trompe, introduire de maniere implicite un comportement différent sur cette classe qui risque aussi d'engendrer tot ou tard des
"Mais pourquoi ca ne marche pas ici" :bug: :aie:

Donc en definitive passer par un constructeur explicite de VRAI clonage me semble plus facilement tracable !

Citation:

---

Envoyé par olibara

implementer Iclonable va, si je ne me trompe, introduire de maniere implicite un comportement différent sur cette classe qui risque aussi d'engendrer tot ou tard des
"Mais pourquoi ca ne marche pas ici" :bug: :aie:

---

Implémenter une interface n'introduit aucun comportement implicite... tu appelles la méthode Clone où tu ne l'appelles pas, c'est comme tu veux... par défaut, les objets de ta classe seront toujours manipulés par référence.

Si tu veux des objets qui, par défaut, sont gérés par valeur, fait des struct et non des classes

Compris 5/5

Merci TomLev