Pourquoi IEnumerator <T> hérite de IDisposable alors que IEnumerator non générique ne le fait pas?

Question

J'ai remarqué que le générique IEnumerator<T> hérite de IDisposable, mais pas de l'interface non générique IEnumerator. Pourquoi est-il conçu de cette manière?

Habituellement, nous utilisons l'instruction foreach pour passer par une instance IEnumerator<T>. Le code généré de foreach a en fait try-finally block qui invoque Dispose() dans finally.

Answer 1

Fondamentalement, c'était un oubli. En C# 1.0, foreachjamais appelé Dispose . Avec C# 1.2 (introduit dans VS2003 - il n'y a pas de 1.1, bizarrement) foreach a commencé à vérifier dans le bloc finally si l'itérateur a implémenté IDisposable - ils ont dû le faire de cette façon, parce qu'étendre rétrospectivement IEnumerator étendre IDisposable aurait brisé l'implémentation de tous IEnumerator. S'ils avaient conclu qu'il est utile pour foreach de disposer des itérateurs en premier lieu, je suis sûr que IEnumerator aurait prolongé IDisposable. Lorsque C# 2.0 et .NET 2.0 sont sortis, cependant, ils ont eu une nouvelle opportunité - nouvelle interface, nouvel héritage. Il est beaucoup plus logique d'avoir l'interface IDisposable afin que vous n'ayez pas besoin d'une vérification de l'exécution dans le bloc finally, et maintenant le compilateur sait que si l'itérateur est un IEnumerator<T>, il peut émettre un appel inconditionnel vers Dispose.

EDIT: Il est incroyablement utile que Dispose soit appelée à la fin de l'itération (mais elle se termine).Cela signifie que l'itérateur peut conserver les ressources, ce qui lui permet, disons, de lire un fichier ligne par ligne. Iterator bloque les implémentations Dispose du générateur qui s'assurent que tous les blocs finally pertinents au "point d'exécution actuel" de l'itérateur sont exécutés quand ils sont éliminés - afin que vous puissiez écrire du code normal dans l'itérateur et que le nettoyage se fasse correctement.

---

Rétrospectivement à la spécification 1.0, il a déjà été spécifié. Je n'ai pas encore été en mesure de vérifier cette déclaration antérieure que l'implémentation 1.0 n'a pas appelé Dispose.

Answer 2

IIRC Le fait d'avoir IEnumerable<T> et IEnumerable est le résultat de IEnumerable antérieurs au modèle de .Net. Je soupçonne que votre question est de la même manière.

Answer 3

Est-ce que IEnumerable` hérite d'IDisposing? Selon le réflecteur .NET ou MSDN. Êtes-vous sûr de ne pas le confondre avec IEnumerator? Cela utilise IDisposing parce que c'est seulement pour l'énumération d'une collection et non pour la longévité.

Answer 4

IEnumerable < T> n'hérite pas IDisposable. IEnumerator < T> hérite cependant d'IDisposable, contrairement à l'IEnumerator non générique. Même lorsque vous utilisez foreach pour un IEnumerable non générique (qui renvoie IEnumerator), le compilateur génère toujours une vérification pour IDisposable et appelle Dispose() si l'énumérateur implémente l'interface.

Je suppose que l'énumérateur générique < T> hérite de IDisposable donc il ne doit pas y avoir un type d'exécution-check-it peut aller de l'avant et appeler Dispose() qui devrait avoir de meilleures performances car il peut être probablement optimisé si l'énumérateur a une méthode Dispose() vide.

Answer 5

Un peu difficile d'être définitif à ce sujet, à moins que vous n'obteniez une réponse d'AndersH lui-même ou d'un de ses proches. Cependant, je suppose que cela se rapporte au mot-clé "yield" qui a été introduit en C# en même temps. Si vous regardez le code généré par le compilateur lorsque "return return x" est utilisé, vous verrez la méthode enveloppée dans une classe d'aide qui implémente IEnumerator; avoir IEnumerator descendant de IDisposable assure qu'il peut nettoyer lorsque l'énumération est terminée.

Answer 6

Je sais que c'est une vieille discussion mais je reasontly écrit une bibliothèque où je IEnumerable de T/IEnumerator de T où les utilisateurs de la bibliothèque pourraient mettre en œuvre itérateurs personnalisés qu'ils devraient juste mettre en œuvre IEnumerator de T.

J'ai trouvé c'est très étrange que IEnumerator de T hérite de IDisposable. Nous implémentons IDisposable si nous voulons libérer des ressources non désaffectées? Cela ne serait donc pertinent que pour les enquêteurs qui détiennent réellement des ressources non gérées - comme un flux d'E/S etc. Pourquoi ne pas laisser les utilisateurs implémenter IEnumerator de T et IDisposable sur leur énumérateur si cela a du sens? Dans mon livre, cela viole le principe de la responsabilité unique - Pourquoi mélanger la logique de l'énumérateur et la disposition des objets.