Salut,
 
J'ai une question à 10 centimes... (comme d'hab )
 
Avec l'histoire de "managed, garbage collector, langage de haut niveau, etc.", je me demandais si par hasard, C# implémentait en natif une notion de transaction/savepoint.
 
Au niveau d'une base de données, une transaction, c'est une série d'instructions (modification de données), qu'on peut à tout moment annuler, avec une simple commande. Un savepoint, c'est grossomodo la même chose (image à un instant T des données, à laquelle on peut revenir, mais qui n'est pas threadsafe - les éléments modifiés sont lockés jusqu'à la validation du traîtement)
 
Je m'explique.
 
Mettons que dans une fonction, je fasse :
 

     
Evidement, ici le cas est simple et ne mérite pas de notion de transaction.
 
Mais dans mon cas, je me lance dans un traîtement lourd, complexe, et qui nécessite trop de mémoire pour travailler dans une duplication de mon environnement de travail.
 
En effet, j'ai un nombre indéfini d'objets que je modifie. Et je ne peux détecter une anomalie qu'une fois TOUS les objets modifiés, en allant relire leur nouvelles valeurs. Dans ce cas, je dois pouvoir annuler, modifier les objets posant problème, et relancer le traîtement (et revérifier, et ainsi de suite jusqu'à ce que toute annomalie soit levée).

La réponse est "Non".
 
Ce que tu propose vient du monde des Bases de données.
C'est possible dans ce cas pask'il suffit de stocker les transactions sur disk pour remettre les choses comme avant.
Mais pour une appli, tu imagines la quantité halluciante de RAM qu'il faudrait pour faire tourner une appli ?
Et la lenteur de l'appli si les 'transactions' sont stockées sur disk ? (Même en RAM ça triplerait facile le temps d'exécution).
Et je parle même pas des appels dans des appels qui feraient que ta transaction doit porter sur 15067 instructions, et le coût en mémoire que ça impliquerait
 
Bref : à mon humble avis, c'est pas compatible avec les besoins de rapidité d'exécution.
 
Sinon, en codant 'intelligemment', tu peux gérer ce genre de pb.
1 - Entrée dans la fonction : recopie de tous les paramètres dans des variables locales.
2 - execution : travail sur les variables locales.
3 - si ton test est OK (commit) : recopier les locales dans les paramètres.
4 - Si ton test est pas Ok (rollback) : laisser les paramètres comme ils sont.
=> C'est super relou pour des gros objets (Clone() et tout ça), ça demande de la rigueur, mais c'est faisable.

C'est en effet la solution vers laquelle je me suis orienté. Mais je me demandais s'il n'y avait pas justement un moyen de gérer ça de façon automatique.
 
A noter justement que le fait qu'une fonction ne travaille qu'avec ses variables locales est justement un début du support de la chose.

Y'a un moyen : faut créer un langage
Ou plus simple : tu fais un plug-in dans VS qui rajoute les lignes de code nécessaires quand il rencontre tes 'begin transaction', 'rollback' et 'commit'.
Bref, tout ça c'est bien prise de tête. Je ne connais pas d'outil qui le fasse tout seul. Et s'il existe, il doit être très controversé (niveau pertes de perf)