... j'ai rien compris !

@SylvainH
C'est que tu ne programmes pas avec un langage moderne

Quand on conçoit un programme, on stocke des informations dans la mémoire de l'ordinateur en allouant de l'espace mémoire. Avec certains langages, il faut désallouer explicitement la mémoire occupée avec une (ou plusieurs) ligne de code. Avec d'autres langages, pas besoin, un mécanisme automatique s'occupe de libérer les espaces qui ne sont plus utilisés : c'est le ramasse miette.

Donc Apple vient de mettre en open source le code de cet outil informatique qui permet de récupérer la mémoire qui n'est plus utilisée par un programme.

C'est pour les informaticiens, pour la gestion de la mémoire dans les applications.

Donc, le titre de l'article aurait pu être : Autozone, le moineau d'Apple

Ok, ok, je sors ===============>

@ Julien

Oui file... :-D le bon de sortie t'attend sur le bureau...

Pourquoi n'avez vous pas écrit cette news en français ?

;-)

À noter que l'intérêt de Java est justement qu'il intègre un ramasse miette, ce qui simplifie le développement vu qu'il n'y a pas à allouer / désallouer la mémoire, la machine virtuelle le fait toute seule.

Franchement, la gestion mémoire est ce qui m'a le plus surpris avec cocoa. On a l'impression de revenir des années en arrière. C'est plutôt une bonne nouvelle s'ils arrivent à faire évoluer le garbage collector pour faire comme en java ou .net. La version Leopard, c'est pas un gc automatique et en plus on peut pas s'en servir pour l'iphone.

@jujuhtst:
Quand je vois la consommation astronomique de RAM d'Azureus sur mon Mac Pro, j'ai des doutes sur l'efficacité du Garbage Collector de Java quand même =p
Vivement la sortie de µtorrent =p

"À noter que l'intérêt de Java est justement qu'il intègre un ramasse miette"

Sinon il reste la solution d'apprendre à programmer correctement et de savoir gérer ses allocations mémoire. Ca permet de profiter ensuite de l'héritage multiple, la surcharge d'opérateurs, ... bref, d'un vrai langage.

Bonne nouvelle. Les applications lourdes devraient s'en voire améliorées sur la gestion mémoire. J'ai beau être de manière globale plutôt contre les garbage collectors(ou du moins pour le fait d'avoir le choix), cette nouvelle annonce un projet qui va de l'avant et fait avancer Darwin dans le bon sens.

"Ca permet de profiter ensuite de l'héritage multiple, la surcharge d'opérateurs"

Heum heum... Je crois que j'ai mal entendu. Voici deux hérésies de la programmation objet. Je suppose que ce que tu as derrière la tête c'est C++. Alors là, parler de cet accident de l'histoire qu'est C++ en tant que "vrai langage", ça me fait mal.

Ensuite, comme pour toutes légendes urbaines qui collent toujours au monde de l'informatique et de la programmation en particulier (celles qui commencent par : "real men do..."), celle du garbage collector qui est fait pour les nuls qui savent pas coder est encore particulièrement tenace. Non, un garbage collector digne de ce nom (je ne parle pas de Java) n'est ni plus ni moins efficace de des désallocations manuelles. As-tu des benchs qui montrent qu'un programme sous Leopard codé en Objective-C avec ou sans Garbage Collector est plus ou moins performant ?

Il faut vous détendre egw, aucune gravité dans le sujet traité ici :) .
Pour ce qui est des différences de performances entre un programme en Objective-C avec et sans garbage collector, je parle d'une certaine future amélioration. Je me base sur le simple fait qu'un garbage collector moderne ne ralentit pas l'application au moment de la desallocation et que le code gérant la mémoire est dispersé partout dans une grosse appli, rendant la maintenance extrêmemetn compliquée, pour gérer ce problème soit on se penche vers la programmation par aspect soit vers un garbage collector(je n'ai jamais regardé le code d'un garbage collector mais certains concepts sont transversaux). Il existe par exemple en AspectC un travail universitaire qui a été effectué qui permet de greffer un aspect à n'importe quel programme écrit en C (c'est pas objet, c'est juste une illustration sur la mémoire) qui va empêcher tout buffer overflow de se produire, en langage objet avec la gestion du cflow on peut définir la durée de vie d'un objet et donc créer un garbage collector assez facilement.
Concernant votre jugement sur le C++, j'éviterai un long discours basé sur les avantages de tel ou tel langage, c'est inutile, idem pour l'héitage multiple et la surcharge d'opérateurs(qui peuvent être utiles comme ils peuvent devenir un frein dans le développement).

[quote]Vivement la sortie de µtorrent =p[/quote]

Quand on voit ce que propose Transmission, on se demande ce que µTorrent pourrait apporter de plus…

Je crois pas trop au ramasse miette de Java. Une appli multifenêtre écrite en java commençait à ramer quand on avait ouvert (et fermé) une dizaine de fenêtre, croyant effectivement qu'il n'y avait pas à vider la mémmoire. Ben non il a fallu sortir les vieux HUnlock ou des trucs comme ça des années 90, et depuis ça fonctionne comme on s'y attendait.

Mais bon, on sait que notre java sur Mac est le moins bien implémenté des trois (de Linux, Win, OS X): du coup si un truc marche bien sur mac, ça carbure sur les autres environnements.

[quote]
Hindifarai [14/11/2008 12:34]

Il faut vous détendre egw, aucune gravité dans le sujet traité ici :) .
[/quote]
Merci, je suis très détendu :) C'est juste que c'est toujours marrant et quelque part réconfortant pour son ego d'avoir des opinions super tranchées sur des sujets somme toute sans gravité, comme tu le rappelles si bien (un peu comme quand j'affirme - je dois pas être le seul ici - avec passion combien Mac OS X est à des années lumières d'un Windows tout pourri, alors qu'en réalité, y a rien de plus secondaire qu'un OS non ?).

Ceci dit mon post répondait à celui de g.lebourgeois, qui me semblait en plein dans le "real men do it...", et non au tien, d'ailleurs sauf erreur de ma part ton second post a tendance à rejoindre le mien :)

Ah la la! Ces informaticiens!
Moi, je programme pas mais j'ai compris.

Ps: private joke pour les informaticiens: quand j'étais à la fac, j'ai appris à programmer en fortran! (ne pas rire svp)

J'ai rien compris....

Le ramasse-miettes (garbage collector) n'impose aucune baisse de performance et apporte un gain certain de productivité aux développeurs, ceux-ci n'étant plus obligés de se préoccuper de l'allocation mémoire qui peut devenir problématique dans des fonctions complexes. Le niveau d'abstraction est ainsi plus élevé, ce qui n'est pas négligeable.
Il suffit de comparer, par exemple, des fonctions d'ouverture et de fermeture de fichiers entre un système qui utilise le garbage collector et un autre sans.

@Zed-K

Utilise Transmission. C'est simple, léger, intégré et efficace.

[quote]Zed-K [14/11/2008 11:50]

Quand je vois la consommation astronomique de RAM d'Azureus sur mon Mac Pro, j'ai des doutes sur l'efficacité du Garbage Collector de Java quand même =p
Vivement la sortie de µtorrent =p

@ Rork :
Fortran reste très utilisé dans le calcul
Quant à rigoler de nos expériences : et bien moi, le peu d'initiation Fortran à laquelle j'ai eu droit, c'était au bon vieux temps de la carte perforée. C'était marrant. On passait plus de temps à retaper les cartes (pour cause de fautes de frappe) qu'à réfléchir au programme lui même. Faut être baby boomer pour avoir connu ça :-))

Moi j'ai tout compris, bande de naze :p

moi ce que je vois avec cette histoire de garbage collector
c'est qu' Apple va encore avoir des emmerdes avec GreenPeace.