"Christophe Lephay" a écrit dans le message de groupe de discussion :
Remplacer bien sur :
using( DisposableTypeB DisposableObject4)
par :
using (DisposableTypeB disposableObject4 = new DisposableTypeB())
L'idée étant qu'on peut enchainer les using avant le bloc :
using(....) using(...) using(...) { }
et créer plusieurs objets du même type dans un unique using(...).
"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le message
de groupe de discussion :
D5D17B1F-DE6E-4C96-B942-3B9B0F33C8A7@microsoft.com...
Remplacer bien sur :
using( DisposableTypeB DisposableObject4)
par :
using (DisposableTypeB disposableObject4 = new DisposableTypeB())
L'idée étant qu'on peut enchainer les using avant le bloc :
using(....)
using(...)
using(...)
{
}
et créer plusieurs objets du même type dans un unique using(...).
"Christophe Lephay" a écrit dans le message de groupe de discussion :
Remplacer bien sur :
using( DisposableTypeB DisposableObject4)
par :
using (DisposableTypeB disposableObject4 = new DisposableTypeB())
L'idée étant qu'on peut enchainer les using avant le bloc :
using(....) using(...) using(...) { }
et créer plusieurs objets du même type dans un unique using(...).
Christophe Lephay
"Christophe Lephay" a écrit dans le message de groupe de discussion :
Si on n'intercepte pas tous les types d'exception, il n'y a pas d'alternative à using ou finally pour garantir la remise en ordre des données, si possible en l'état valide antérieur à la levée d'exception.
A noter que la question ne se pose que pour les données non managées, le gc et la clr s'occupant intégralement des autres, y compris en présence d'exception.
"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le message
de groupe de discussion :
D5D17B1F-DE6E-4C96-B942-3B9B0F33C8A7@microsoft.com...
Si on n'intercepte pas tous les types d'exception, il n'y a pas
d'alternative à using ou finally pour garantir la remise en ordre des
données, si possible en l'état valide antérieur à la levée d'exception.
A noter que la question ne se pose que pour les données non managées, le gc
et la clr s'occupant intégralement des autres, y compris en présence
d'exception.
"Christophe Lephay" a écrit dans le message de groupe de discussion :
Si on n'intercepte pas tous les types d'exception, il n'y a pas d'alternative à using ou finally pour garantir la remise en ordre des données, si possible en l'état valide antérieur à la levée d'exception.
A noter que la question ne se pose que pour les données non managées, le gc et la clr s'occupant intégralement des autres, y compris en présence d'exception.
Jérémy Jeanson
Merci, mais ma question ne se pausait pas sur le catch. J'utilise déjà la capture d'erreur en filtrant de l'erreur la plus ciblée vers la plus large.
Non la question un était sur le fait de mettre la valeur null à un objet alors que celui-ci a été déclaré uniquement dans la méthode. Il s'agit d'une vieille habitude prise après le passage de .net 1.0 à 1.1 quand j'ai rencontré quelques soucis de Flush de Stream... enfin je m'égare.
J'ai pris l'haitude de passer à null ces variable en fin de méthode par prudence mais je n'ai jamais trouvé de tests démontrant l'impact ou l'utilité de cette méthode.
Je fais donc ceci au cas où le comportement du GC et du framework changerait encore une foi (et c'est dire qu'il a changé en 7ans, par exemple le fait que les variables déclarées dans une classe ne soient plus triées automatiquement par type comme par le passé). -- Jérémy JEANSON MCP http://www.jjeanson.fr
Merci, mais ma question ne se pausait pas sur le catch. J'utilise déjà
la capture d'erreur en filtrant de l'erreur la plus ciblée vers la plus
large.
Non la question un était sur le fait de mettre la valeur null à un objet
alors que celui-ci a été déclaré uniquement dans la méthode. Il s'agit
d'une vieille habitude prise après le passage de .net 1.0 à 1.1 quand
j'ai rencontré quelques soucis de Flush de Stream... enfin je m'égare.
J'ai pris l'haitude de passer à null ces variable en fin de méthode par
prudence mais je n'ai jamais trouvé de tests démontrant l'impact ou
l'utilité de cette méthode.
Je fais donc ceci au cas où le comportement du GC et du framework
changerait encore une foi (et c'est dire qu'il a changé en 7ans, par
exemple le fait que les variables déclarées dans une classe ne soient
plus triées automatiquement par type comme par le passé).
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
Merci, mais ma question ne se pausait pas sur le catch. J'utilise déjà la capture d'erreur en filtrant de l'erreur la plus ciblée vers la plus large.
Non la question un était sur le fait de mettre la valeur null à un objet alors que celui-ci a été déclaré uniquement dans la méthode. Il s'agit d'une vieille habitude prise après le passage de .net 1.0 à 1.1 quand j'ai rencontré quelques soucis de Flush de Stream... enfin je m'égare.
J'ai pris l'haitude de passer à null ces variable en fin de méthode par prudence mais je n'ai jamais trouvé de tests démontrant l'impact ou l'utilité de cette méthode.
Je fais donc ceci au cas où le comportement du GC et du framework changerait encore une foi (et c'est dire qu'il a changé en 7ans, par exemple le fait que les variables déclarées dans une classe ne soient plus triées automatiquement par type comme par le passé). -- Jérémy JEANSON MCP http://www.jjeanson.fr
Christophe Lephay
"Jérémy Jeanson" a écrit dans le message de groupe de discussion : #
Merci, mais ma question ne se pausait pas sur le catch. J'utilise déjà la capture d'erreur en filtrant de l'erreur la plus ciblée vers la plus large.
Non la question un était sur le fait de mettre la valeur null à un objet alors que celui-ci a été déclaré uniquement dans la méthode. Il s'agit d'une vieille habitude prise après le passage de .net 1.0 à 1.1 quand j'ai rencontré quelques soucis de Flush de Stream... enfin je m'égare.
J'ai pris l'haitude de passer à null ces variable en fin de méthode par prudence mais je n'ai jamais trouvé de tests démontrant l'impact ou l'utilité de cette méthode.
Je ne comprends pas trop, à vrai dire :
Lorsqu'on sort du bloc, le gc supprime la référence, du coup je ne vois pas trop l'effet attendu par le fait de leur affecter null. Dans le cas des streams, les ressources non-managées posent problème dès qu'elles ne sont pas explicitement libérées, et je ne vois pas trop là encore quel effet pourrait avoir le fait de les mettre à null (à moins de forcer un collect derrière ?).
"Jérémy Jeanson" <jeremy.jeanson@free.fr> a écrit dans le message de groupe
de discussion : #91haz6WJHA.5084@TK2MSFTNGP03.phx.gbl...
Merci, mais ma question ne se pausait pas sur le catch. J'utilise déjà la
capture d'erreur en filtrant de l'erreur la plus ciblée vers la plus
large.
Non la question un était sur le fait de mettre la valeur null à un objet
alors que celui-ci a été déclaré uniquement dans la méthode. Il s'agit
d'une vieille habitude prise après le passage de .net 1.0 à 1.1 quand j'ai
rencontré quelques soucis de Flush de Stream... enfin je m'égare.
J'ai pris l'haitude de passer à null ces variable en fin de méthode par
prudence mais je n'ai jamais trouvé de tests démontrant l'impact ou
l'utilité de cette méthode.
Je ne comprends pas trop, à vrai dire :
Lorsqu'on sort du bloc, le gc supprime la référence, du coup je ne vois pas
trop l'effet attendu par le fait de leur affecter null. Dans le cas des
streams, les ressources non-managées posent problème dès qu'elles ne sont
pas explicitement libérées, et je ne vois pas trop là encore quel effet
pourrait avoir le fait de les mettre à null (à moins de forcer un collect
derrière ?).
"Jérémy Jeanson" a écrit dans le message de groupe de discussion : #
Merci, mais ma question ne se pausait pas sur le catch. J'utilise déjà la capture d'erreur en filtrant de l'erreur la plus ciblée vers la plus large.
Non la question un était sur le fait de mettre la valeur null à un objet alors que celui-ci a été déclaré uniquement dans la méthode. Il s'agit d'une vieille habitude prise après le passage de .net 1.0 à 1.1 quand j'ai rencontré quelques soucis de Flush de Stream... enfin je m'égare.
J'ai pris l'haitude de passer à null ces variable en fin de méthode par prudence mais je n'ai jamais trouvé de tests démontrant l'impact ou l'utilité de cette méthode.
Je ne comprends pas trop, à vrai dire :
Lorsqu'on sort du bloc, le gc supprime la référence, du coup je ne vois pas trop l'effet attendu par le fait de leur affecter null. Dans le cas des streams, les ressources non-managées posent problème dès qu'elles ne sont pas explicitement libérées, et je ne vois pas trop là encore quel effet pourrait avoir le fait de les mettre à null (à moins de forcer un collect derrière ?).
Delf
Après mûre réflexion, Arnaud Lhopiteau a écrit :
En fait, l 'objet cache a ce rôle de Factory, car il met à dispositions ces objets. Si on ne peut "wrapper" les références pour que les compteurs d'utilisation soient décrémentés lorsque ces "wrappers" sont recyclés, je ne vois que la solution "façon COM".
Chaque objet mis dans mon Cache est encapsulé dans un objet container.
Mis à part y mettre un flag d'utilisation (bien que ça ne résoud pas le problème, car un objet utilisé, dans le temps ne signifie rien ici), je ne vois pas quoi faire...
Après mûre réflexion, Arnaud Lhopiteau a écrit :
En fait, l 'objet cache a ce rôle de Factory, car il met à
dispositions ces objets.
Si on ne peut "wrapper" les références pour que les compteurs
d'utilisation soient décrémentés lorsque ces "wrappers" sont recyclés,
je ne vois que la solution "façon COM".
Chaque objet mis dans mon Cache est encapsulé dans un objet container.
Mis à part y mettre un flag d'utilisation (bien que ça ne résoud pas le
problème, car un objet utilisé, dans le temps ne signifie rien ici), je
ne vois pas quoi faire...
En fait, l 'objet cache a ce rôle de Factory, car il met à dispositions ces objets. Si on ne peut "wrapper" les références pour que les compteurs d'utilisation soient décrémentés lorsque ces "wrappers" sont recyclés, je ne vois que la solution "façon COM".
Chaque objet mis dans mon Cache est encapsulé dans un objet container.
Mis à part y mettre un flag d'utilisation (bien que ça ne résoud pas le problème, car un objet utilisé, dans le temps ne signifie rien ici), je ne vois pas quoi faire...
Delf
Arnaud Lhopiteau avait prétendu :
Ce qui n'est pas le cas, disons plutôt dans des objets normaux implémentant l'interface IDisposable, idéalement utilisé dans un block "using".
Pourquoi 'normaux' ? N'implémente t-on pas IDisposable si l'objet dispose de membres implémentant à leur tour cette interface ? J'ai toujours procédé comme ça.
Merci.
Arnaud Lhopiteau avait prétendu :
Ce qui n'est pas le cas, disons plutôt dans des objets normaux
implémentant l'interface IDisposable, idéalement utilisé dans un block
"using".
Pourquoi 'normaux' ? N'implémente t-on pas IDisposable si l'objet
dispose de membres implémentant à leur tour cette interface ? J'ai
toujours procédé comme ça.
Ce qui n'est pas le cas, disons plutôt dans des objets normaux implémentant l'interface IDisposable, idéalement utilisé dans un block "using".
Pourquoi 'normaux' ? N'implémente t-on pas IDisposable si l'objet dispose de membres implémentant à leur tour cette interface ? J'ai toujours procédé comme ça.
