Reprise du message précédent :
https://msdn.microsoft.com/en-us/li [...] .110).aspx

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

l'exemple avec le if bidule==null

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   (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)

 
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

 
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.

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

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).

Sondage: pour organiser et mettre en ligne des photos, vous utilisez quoi?  
 
Pour le moment j'ai Picasa, avec un machin pour partager le DB entre plusieurs users, mais c'est un peu fini...
 
Idéalement, un truc qui permettrait de centraliser tout ça sur le NAS serait top.
 

owncloud  

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

 
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.

Flickr ?

tree

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

la version saas

Nray > https://farmbot.io/

lol

Excellent ce farm bot

Ça donne envie de faire des trucs qui sont pas que des softs mais qui agissent/se déplacent IRL. J'ai déjà dit, mais je remet un couche : quand je serai pété de thune (   ) je monterai une startup pour le fun avec nraynal (entre autre) pour faire des bidules réels

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.

Samedi j ai du mo de ca aurai ete le bon moment pour couler ma dalle ou monter le chalet

C'est moi ou soundcloud et peut-être d'autre, fonctionne mal.
 
Si je fais une progression logique de ma musique je souhaiterais avoir le dernier morceau à la fin de la liste !
Là il présente les derniers morceau en premier.
 
 
 
Encore un coup des saxon.

Quand tu penses que marie trintignant elle n a fait que des mauvais film, et cantat plein de bon cd, gu te dit que les lois sont mal faite

Hello,
 
Je voudrais un multimetre basique, vous recommandriez quoi ? c'est surtout pour tester si 220v ou pas 220v dans certaines lampes de la maison qui ont tendance a griller souvent
 
http://www.distrelec.ch/fr/outils- [...] =10&page=1

Putain la tv
....

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.

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

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

Plus 1 avec nray.
Le probleme vient soit des.point de centre soit des lampes

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.

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

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

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

JE préfère farmer du pokemon

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

Mais 0x sait pas couler de dalle, qui va le faire ?

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.

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

Saloperie de correcteur iphone

Ca se désactive
 
Généralement ceux qui essaient le réactivent rapidement

 
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.

 
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++.  

 
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...