[blabla@olympe] Le topic du modo, dieu de la fibre et du monde

 
Sauf que le RAII pose un problème sérieux quand même, on te dit "faut libérer les ressources dans le destructeur", mais on te dit aussi qu'un destructeur C++ ne doit pas lancer d'exception ("You can throw an exception in a destructor, but that exception must not leave the destructor; if a destructor exits by emitting an exception, all kinds of bad things are likely to happen because the basic rules of the standard library and the language itself will be violated." ), donc c'est pas toujours si pratique que ça...

 
Déjà un objet Disposable, on doit le disposer, c'est la philosophie du truc. Je te fournis une interface facile à utiliser, tu l'utilises, point. Tu n'es pas sensé choisir les moments où tu l'utilises et les fois où tu comptes sur le finalizeur. Tu peux évidemment mais ce n'est pas la philosophie du concept.
 
Du coup au final ce qui me chiffonne c'est simplement de devoir utiliser ce pattern alors que précisément la gestion automatisée des ressources est l'un des objectifs des langages haut niveaux. Et comme ce pattern est une conséquence directe de l'existence du GC, je me posais la question de l'utilité de ce dernier, utilité qui comme tu l'as fait remarqué est moins flagrante face aux dernières versions de c++.  

 
depuis que j'ai changé de marques d'ampoules, j'ai arrêté d'en griller.  
 
fun fact :j'avais des keria avec échange. Tous les 2 mois, je passait à la boutique, et on me refilait gratuitement leurs remplaçantes, qui regrillait toujours aussi vite.

Je ne pas dit que c'était plus rapide. En fait j'ai dit exactement le contraire mais j'ai eu la flemme de détailler ce qui me semblait évident.

Sinon ce que tu dis est vrai, mais ça n'est en rien différent du C++, d'un côté tu implémentés IDisposeable, de l'autre tu écris un destructeur. Le pb d'Hepha c'est pas tant ce qui doit être fait, mais quand le nettoyage doit être exécuté.

Edit: effectivement, le RAII à un léger avantage ici parce que le nettoyage de l'objet Parent est bloqué même si un close a été effectué, mais en pratique, ça n'arrive pas souvent que ça pose un réel pb

Oui mais non dispose c'est pas plus rapide que close, l'intérêt c'est que using/dispose fonctionne proprement en cas d'exceptions et avec des resources imbriquées,  c'est simple à utiliser correctement.

Ça empêche pas remarqués, nray cherche du boulot tu peux lui faire couler ta dalle :o

JE préfère farmer du pokemon
http://reho.st/medium/self/b6b9796 [...] 8aff10.png

Je peux streamer comme ça, mais il faut que je baisse la qualité.

Sauf si tout est à refaire électriquement chez toi, ce sont probablement les ampoules qui sont pourries. Change de marque.

J'avoue c'est classe.  :jap:  
Reste plus qu'il détecte et allume les limaces et c'est bon.  :D

En fait, quels sont les cas d'utilisation de Dispose() ?
 
Si tu dois libérer immédiatement la ressource, parce qu'elle doit être utilisée par ailleurs (un fichier "totoz" écrit par toi et écrit/lu par un autre processus, par ex), je pense qu'il vaut largement mieux faire un close()/unlock() et garder le handle sur le fichier. C'est bien plus rapide que de faire à chaque fois une allocation (qui in fine va faire un appel système pour obtenir le handle du fichier) puis un Dispose() à chaque fois que tu veux ouvrir et écrire à nouveau le fichier. C'est une gestion manuelle, mais c'est vrai aussi en C++. Sinon, effectivement, si tu fais des new File("totoz" ) à tire larigot en laissant le GC s'épuiser à les fermer un à un, tu vas occuper des milliers de handles de fichiers, là où en C++ le RAII nettoie proprement derrière lui.
Idem pour la gestion de sockets.
 
Si tu fais juste une seule ouverture/fermeture du fichier, tu t'en fous que le GC soit non déterministe. Tu fais ton close() à la fin et basta.
 
Au final, Dispose(), le cas d'utilisation que je vois, c'est si il y a un besoin urgent de faire un nettoyage quand le GC n'a pas pu passer. Ce sont vraiment dans des applications très spécifiques où les perfs sont critiques (auquel cas de toute façon, la question se pose si le C++ n'est pas plus approprié). Perso je n'ai jamais eu à l'utiliser.

et tu penses que ton 220V il aurait quoi comme défaut ?

10e en gsb
Sinon prend celui que t a piqué à l ecole et change les piles

Les barbus ont égorgé un curé.
Hop 5 points pour marine
Et dire que je verrai ptet pas ca :/
Une guerre civile.
Et mon meilleur pote est tunisien, j ai pas de chance, je vais pas l heberger chez moi si on les rafles quand meme.

Oui donc on en revient à la remarque initiale : c'est à l'utilisateur d'appeler Dispose tout le temps, et donc de gérer manuellement tout ce qui n'est pas la mémoire gérée par le GC.
 
Je n'ai pas dit que c'était pas bien ou que c'était difficile, simplement j'ai l'impression d'avoir la charge d'un truc qui se fait par défaut tout seul en C++, tandis que par ailleurs je ne trouve pas flagrant le gain apporté par le GC.

 
la version ligne de commande ou fenêtrée ?

Flickr ?

 
Ca répond pas au besoin d'organisation, si?
 
Enfin, ce qui est top avec Picasa, c'est l'organisation en dossiers par date (ça, c'est simpliste) et les albums : une photo peut être dans un ou plusieurs albums (mais physiquement elle n'est qu'une fois dans la collection), et tu choisis de publier (ou pas) par album.
 
Sans compter les features sympa d'impression, recadrage, yeux rouges, etc... simples à utiliser.

 
J'avoue que "xxx is not disposed" sans avoir à lancer .Net Memory Profiler ça serait quand même bien :/

D'une c'est pas une question très difficile, et de deux la question est inversée (comme tu le notes tu vas plutôt disposer par défaut) et tu vas vite te rendre comptes d'une resource utilisée après dispose.

Qu'une classe soit disposable ou pas est généralement pas difficile à imaginer, et il y a probablement des linters pour une analyse statique basique (est-ce que tu dispose bien d'un IDisposable qui n'est pas leaké).

Bah non pour la raison déjà mentionnée plusieurs fois que l'exécution du finalizer n'est pas déterministe (et fondamentalement pas garanti), tu vas vite te retrouver avec des deadlocks et des exhaustions de resources si t'as un GC autre que du refcounting (ou que tu crées des cycles avec un RC), ça devient pari et prières (que t'aies suffisamment de pression mémoire, et qu'aucun de tes objets disposable ne se retrouvent en oldgen).

ou un truc comme ça ? http://www.ldlc.com/fiche/PB00208766.html

 
Du coup il faut se poser la question quand on utilise une ressource si on a besoin de la libérer tout de suite ou non. Pour éviter cela, la bonne pratique c'est de toujours Disposer ce qui est Disposeable (donc faire du RAII manuel, qui demande quand même d'inspecter la classe qu'on utilise pour voir si elle est Disposable). C'est sûr plutôt que de faire ça je peux me demander ce que je peux laisser se finalizer tranquillement en temps voulu, mais au final on en revient au fait que c'est l'utilisateur qui doit se poser les questions, et savoir quelles ressources sont utilisées par la classe qu'il appelle.

 
du coup c'est plus vraiment le meme budget : il te faut un deuxième PC, un boitier d'acquisition, etc...
je postule que c'est moins cher d'avoir un CPU avec plus de core et d'en dedier 1-2 à l'encodage

Encore une fois : soit tu appelles Dispose() quand ça te convient, soit tu t'appuies sur le GC qui appellera le finalizer (avant de détruire l'objet) quand ça lui convient  [:spamafote] (sachant que comme dit Masklinn il obéit à des critères d'occupations mémoires lui).

C'est pas bien différent d'une ressource en C++ : soit tu libères la ressource quand tu veux (genre file.close()), soit tu laisses faire le mécanisme de gestion de la mémoire (en l'occurrence RAII) qui va appeler ton destructeur (contenant ton close) à la mort de la variable, ce qui peut vouloir dire à la sortie du scope, ou plus tard, ou carrément à la sortie de l'application c'est selon la portée de la variable.

J'ai fait beaucoup de C# et de C++, ce que tu gagnes avec RAII c'est que la durée de vie de ta variable == la durée de vie de ta ressource... ça change pas trop le fait de devoir se poser la question de cette durée de vie au final (mais ça fait du code moins verbeux, pas besoin de using {} ou de finally {} côté appelant)

StreamReader sr = null;
      try {
         sr = new StreamReader(filename);
         txt = sr.ReadToEnd();
      }
      finally {
         if (sr != null) sr.Dispose();     
      }

[:nul] l'exemple avec le if bidule==null