lecture sur le Disposez le modèle , je Voir la documentation à plusieurs reprises se référer à "Nettoyer Géré et non géré code". Et dans la mise en oeuvre canonique de la méthode Mais suis-je, le faible débutant, de savoir quels types sont gérés et qui sont non gérées? Dispose , je vois des flux spécifiques (selon que disposer est vrai ou faux) dédié au nettoyage des objets gérés par rapport aux objets gérés par rapport aux objets non gérés. < / p>
5 Réponses :
Si vous ne le savez pas, les types que vous utilisez sont probablement gérés.
Les types non gérés font référence à des types qui ne sont pas sûrs, c'est-à-dire non conformes aux exigences de sécurité CLR.
Je ne comprends pas le bowvote? La question était spécifiquement sur la manière de différencier les types gérés et non gérés?
Toutes les autres réponses concernaient la question des idées, plutôt que la question gérée / non gérée!?
Toujours pas d'explication du deuxième captivote ...
Je suis d'accord, un objet Idisposable doit toujours être éliminé, mais cela ne répond pas à la question à propos de géré vs. non gérée.
Semblable à mon autre commentaire, comment savez-vous qu'un type, comme vous le dites, ne correspond pas aux exigences de sécurité CLR? C'est à dire. Si je devais écrire un plugin réflecteur pour signaler la "non gymnastique" d'un type sélectionné, quel serait mon plugin inspecter sur ce type pour faire un jugement définitif?
Je suggérerai simplement de détruire toutes les ressources après les utiliser. Tout cela dépend généralement d'une ressource système telle que des sockets et des ressources de flux que vous souhaitez libérer explicitement. En cas de doute, allez-y et disposez. Vous économiser beaucoup de problèmes de débogage à long terme. Habituellement, lorsque vous appelez le code qui n'est pas écrit dans .net, vous pouvez supposer que ce n'est pas "code géré".
La version courte est la suivante: tout ce qui implémente également Idisposable doit être appelé dans votre Disposer méthode. FXCop vous dira également si vous manquez quelque chose (ou n'utilisant pas Idisposable du tout quand vous devriez être).
Bien que cela ne réponde vraiment pas à la question, je ne suis plus convaincu qu'une bonne réponse existe. Cela fournit la meilleure solution pratique aux problèmes qui se posent lorsqu'un programmeur ne peut pas porter un jugement concernant la "gestion" d'un type, mais je pense qu'un programmeur qui souhaite une heuristique définitive pour que ce jugement soit tout simplement mal de la chance.
géré ou non géré n'a pas d'importance. Si une classe implémente l'interface Idisposable, vous devez appeler Disposer () lorsque vous avez terminé avec l'objet. Alternativement (de préférence) utiliser le Utilisation de la déclaration avoir éliminer () appelé automatiquement lorsque l'objet tombe hors de portée.
@ Rob:
La réponse est toujours la même. Si votre classe gère des objets internes qui implémentent Idisposable, il devrait être de la mise en œuvre non souhaitée. Dans votre disposition (), appelez, appelez ces objets.
Je pense que la question posait de la perspective de la conception de Idisposables - c'est-à-dire ce qui devrait et ne devrait-il pas être libéré lorsque je dispose contre la finalisation.
@Thorarin - Je pense que le point robe est que si vous mettez en place le modèle de jeton classique, vous disposez d'un drapeau indispositif pour indiquer s'il est disposé en raison d'un appel à disposer, ou en raison de l'exécution du finaliser. Dans ce dernier cas, vous devez faire attention à ne pas disposer d'autres objets gérés car ils ont déjà été recueillis. Sur une fois explicitement appelée à partir d'une méthode Dispose (), il est prudent de les éliminer. La ressource non géographique devrait toutefois être disposée dans les deux cas.
J'ai tendance à envers l'approche de Gestapo sur celui-ci: si le finaliseur est appelé du tout, placez-vous fort au programmeur pour corriger leur code.
Universain signifie des objets Win32 natifs, principalement des poignées; et références à des objets bruts. Ce sont des ressources qui ne sont pas sous le contrôle de (ou gérées par) le .NET CLR.
Droite, mais comment un développeur strict-.net serait-il trop jeune pour avoir utilisé Win32, COM, etc. savoir qu'une ressource n'est pas sous le contrôle du CLR, ni pire encore, dépend sur une ressource qui n'est pas sous le contrôle du CLR? Je veux dire, comment savez-vous que, par exemple, une poignée est non gérée? Probablement expérimenter. Mais en l'absence de cette expérience, comment est un programmeur plus vert pour l'obtenir à chaque fois? Je soutiens que la présence de, disons, l'interface Idisposable ne suffit pas; Votre programmeur moyen n'est pas appris à vérifier la documentation de chaque type pour une mention d'Idisposable.
Je dis le contraire. D'Idisposable est là que de disposer. Point final. De cette façon, le tendre jeunesse n'a jamais besoin d'être exposé le traumatisme de com.