Forme.ShowDialog() et de disposer
Si j'ai une méthode comme ceci:
public void Show()
{
Form1 f = new Form1();
f.ShowDialog();
}
Dois-je toujours besoin d'appeler disposer sur la forme, même si hors de portée, qui seront éligibles pour la collecte des ordures.
De certains essais, l'appel de cette méthode Show() plusieurs fois .. à un certain point, il semble que la GC recueille depuis que je puisse voir le mémoire de dopage alors qu'il descend à un certain point dans le temps.
À partir de MSDN il semble dire, vous DEVEZ disposer d'appel lorsque le formulaire n'est plus nécessaire.
OriginalL'auteur pdiddy | 2012-07-12
Vous devez vous connecter pour publier un commentaire.
Dans votre exemple, non, il est peu probable qu'il serait particulièrement utile. Les formulaires de ne pas tenir sur une quantité importante de ressources, donc si il faut un peu plus pour une certaine partie de son code pour obtenir nettoyé, il ne va pas poser un problème. Si cette forme se trouve tout juste à s'accrocher à un contrôle qui est utilisé, par exemple, la lecture d'une vidéo, alors peut-être que c'est effectivement sur un nombre important de ressources, et si vous ne disposer de ces ressources dans la méthode dispose alors, il vaut la peine de prendre le temps d'appeler les éliminer. Pour 99% de vos formulaires cependant, leur méthode dispose est vide, et si vous appelez ou pas, c'est peu probable (ou tout perceptible) effet sur votre programme.
La raison que c'est il y a principalement pour activer la possibilité de disposer de ressources dans ces 1% des cas où c'est important.
Il est également intéressant de noter que lorsqu'une
Form
est fermé sesDispose
méthode est déjà appelé. Vous ne devez jamais ajouter unusing
ou expliciteDispose
appeler si vous souhaitez vous débarrasser de l'une des Formes les ressources avant que le formulaire est fermé. (Qui ressemble généralement une mauvaise idée pour moi). C'est assez facile à tester. Il suffit de créer un projet avec deux formes. La deuxième forme associer un gestionnaire d'événement pour laDisposing
événement et afficher une boîte de message ou quelque chose. Ensuite, lorsque vous créez une instance de la forme et de l'afficher (comme une boîte de dialogue ou pas), vous verrez que lorsque vous fermez la boîte de message apparaîtra tout de suite, même si vous conservez la 'Forme' exemple autour et sans jamais avoir à ajouter unusing
ouDispose
appel.Form1
que les besoins d'élimination, mais parce que personne n'est à l'appelant qu'il n'est jamais disposé de façon déterministe.Qui suppose qu'ils sont instanciés directement et pas par d'autres moyens tels que la réflexion. Je suis d'accord que la plupart du temps il n'y a pas de différence fonctionnelle, mais comme un acte d'entrer dans l'habitude, il convient d'utiliser
using
de toute façon, c'est pas exactement comme il y a un bon avantage en matière de performances, de ne pas utiliserusing
si il y a seulement un appel. Et il suppose également qu'une personne modifiant laDispose
méthode va prendre sur eux pour vérifier qu'il est disposé partout et ne pas assumer que c'est à cause de la convention acceptée deIDisposable
. Je n'irais pas vérifier par défaut.Je ne comprends pas ce que vous obtenez à la boîte de dialogue peu... dans la Fpo exemple, il est montré comme un dialogue et est encore utilisable une fois qu'il a été fermé et vous pouvez facilement de l'envelopper dans un appel dispose...
Bien, je n'étais pas très clair quand je dit que. Ce que j'étais en ce qui implique, c'est que c'est une bonne idée de disposer des éléments qui nécessitent de disposer de,
using
est juste un moyen facile de le faire la plupart du temps. Je suis en désaccord avec vos sentiments sur la forme, mais je suppose qu'il serait ouvert à débat pour savoir qui est leur faute, il serait pour l'introduction de la fuite de mémoire. Aussi, pour être complet, vous pouvez avoir une forme qui n'est pas montré comme un dialogue dans unusing
, mais vous ne pouvez pas être en mesure de montrer pour très longtemps avant qu'il soit disposé lolest trop générale pour faire un point sur, à mon avis. À la recherche après le cycle de vie des formes n'est pas difficile étant donné que nous avons la
Closed
événement. Je suis en désaccord, qu'il ajoute aux coûts de développement suffisant pour faire de mon approche par défaut à "disposer de rien", par opposition à défaut d'en disposer". À mon avis, le très faible coût de l'élimination des choses est assez pour justifier de le faire par défaut, considérant qu'il assure la pérennité de moi contre d'éventuelles fuites de mémoire - un très coûteux session de débogage.OriginalL'auteur Servy
Ce qui tend à se produire, si l'article est purement géré ressources, l'appelant dispose est pas nécessairement nécessaire, mais est fortement conseillé parce qu'il fait de l'élimination déterministe. Il n'est pas toujours nécessaire (dans un sens technique du terme), parce que ces ressources gérées serait probablement eux-mêmes faire l'objet d'GC, ou il n'y a vraiment rien à jeter par défaut et c'est un point d'extensibilité.
Pour non géré ressources, la Modèle Dispose conseille la mise en œuvre d'un finaliseur, qui sera appelée sur GC. Si les types ne mettent pas en œuvre l'outil de finalisation et d'en disposer n'est pas appelé, il est possible (bien, très probable) que les ressources seraient gauche non gérée. Les finaliseurs sont la dernière chance offerte par le moteur d'exécution pour la compensation de vos trucs - ils sont également limitées dans le temps.
Remarque, qu'il ne pas faire de GC ou de la mémoire gérée de remise en état déterministe, l'immersion est pas
delete
à partir de C++. Un élément disposé pourrait être un long chemin loin de la réalité recueillis. Cependant, dans le monde géré, vous ne se soucient pas déterministe de la collection, uniquement à la gestion des ressources en d'autres termes, l'élimination.Cela dit, je m'assure toujours que j'appelle Jetez-les ou utilisez un
using
déclaration si un type est jetable, indépendamment du fait qu'il utilise gérés ou non de ressources - c'est la convention:Mise à jour:
Après une discussion avec Servy j'ai l'impression d'avoir à exprimer ce point que le raisonnement derrière mon avis d'éliminer si possible. Dans le cas de
MemoryStream
, c'est clairement un type jetable, mais le fait de ne pas jeter n'importe quoi actuellement.En s'appuyant sur ce, cependant, est de s'appuyer sur la mise en œuvre de
MemoryStream
. Ont été de ce changement d'inclure une ressource non managée, cela voudrait alors dire que la dépendance surMemoryStream
n'ayant rien à jeter devient problématique.Lorsque cela est possible (comme c'est le cas avec
IDisposable
) je préfère me fier sur le contrat public. De travail contre le contrat dans ce cas serait de dire que je suis sûr à partir de sous-jacents de la mise en œuvre des changements.Dispose
sur un objet sont ceux qui, soit (1) garder la trace de l'objet de la durée de vie serait particulièrement lourde, et l'objet est connu pour être de type particulier qui s'auto-nettoie correctement même quand ils ne sont pas éliminés; et/ou (2) l'objet a un peu cassé la conception qui utilise saDispose
méthode purement inconditionnellement pour nettoyer un passé dans l'objet (ex:StreamReader
), et le fournisseur de ce passé-dans l'objet souhaite en conserver la propriété.Je suis d'accord. J'ai l'habitude d'avoir une situation où le cycle de vie était hors de mon contrôle. Je suis juste en faisant le point que par défaut j'ai essayer de disposer de tout. Bien sûr, avec toutes les généralisations, il y a des exceptions.
puis-je vous demander: serait-elle différente si le formulaire ne sont pas assignés à un pointeur? Comme
new Form().ShowDialog()
? Ou serait-ce encore pire, car si je ne garde pas un pointeur, je ne suis pas capable de la jeter? (La Forme en particulier n'est nécessaire pour calculer et afficher de l'information supplémentaire sur demande)Si vous n'avez pas à tenir à la référence de la
Application.OpenForms
propriété de le faire. Lorsque toutes les références sont supprimées, la GC finira par jeter via le finaliseur si elle est mise en œuvre. Dans le cas d'unForm
, de ne pas garder tenir de la référence n'est pas trop grave.OriginalL'auteur Adam Houldsworth
Bien que vous avez rarement manuellement éliminer en C# de l'omi, vous pouvez essayer comme ça:
Puis à la dernière accolade de l'utilisation d'une partie, il obtiendra éliminés automatiquement.
OriginalL'auteur Gerald Versluis
Vous pouvez simplement faire:
OriginalL'auteur Druid
Si vous voulez explicitement supprimer, utilisez
Cela garantit Dispose() est appelée, comme il se produit immédiatement
OriginalL'auteur James
ShowDialog a pour effet de garder les objets GDI vivant. Afin d'éviter GDI de fuite, nous devons disposer ShowDialog de façon appropriée. Où que de Montrer la méthode n'a pas de l'implication et de la GDI sera publié de manière appropriée. Il est recommandé de disposer de showDialog et ne reposent pas sur le Garbage collector.
OriginalL'auteur Mendy