Discussion :

[Furikawari]

Les pointeurs sont intelligents n'ont de lourd que les noms de types à rallonge -- du moins en C++ tant que l'on ne passe pas par des typedef.
En revanche, ils ont une chose que ne possèdent pas les GCs : le déterminisme. Sur la mémoire, c'est sûr qu'une approche non déterministe peut s'avérer plus efficace, et sans mise en danger du système. Cependant, sur les autres ressources la différence est critique.

En cela, la solution de C# est intéressante : ce langage différencie la mémoire qui est collectée quand bon lui semble et les ressources pour lesquelles on peut disposer d'une finalisation déterminisme et pseudo-implicite (avec using) -- en Java, on passe à l'explicite lourd (try-finalize); OCaml, je ne connais pas.

Quant aux cycles ... ma foi, pour l'instant ils ne me gênent pas. Et combien même en réfléchissant un minimum, on voit vite où mettre du shared_ptr<>, et où mettre du weak_ptr<>

Clairement il n'existe pas de solution élégante (RAII) pour la gestion de ressource autre que la mémoire en java. C'est l'une des seules choses que je concède aux fanboys C++.

Par contre, les GC ont fait des progrès tels qu'il n'existe plus d'application où il est préférable d'avoir une gestion manuelle de la mémoire. (à cet endroit là je devrais mettre un lien vers une vidéo d'une prez sur le GC et le temps réel, mais je ne l'ai pas sous la main... peut être ce soir si je n'ai pas oublié !)

[gorgonite]

Par contre, les GC ont fait des progrès tels qu'il n'existe plus d'application où il est préférable d'avoir une gestion manuelle de la mémoire. (à cet endroit là je devrais mettre un lien vers une vidéo d'une prez sur le GC et le temps réel, mais je ne l'ai pas sous la main... peut être ce soir si je n'ai pas oublié !)

as-tu déjà entendu parlé de WCET ?
si oui peux-tu expliquer l'absence de risque d'un GC dans ce domaine ?

[alex_pi]

as-tu déjà entendu parlé de WCET ?
si oui peux-tu expliquer l'absence de risque d'un GC dans ce domaine ?

Worst Case Execution Time ? Si oui, c'est quoi le rapport ? Si non, de quoi parles tu ?

[gorgonite]

Worst Case Execution Time ? Si oui, c'est quoi le rapport ? Si non, de quoi parles tu ?

oui
si tu ne vois pas le rapport entre l'utilisation d'un GC et les problèmes de WCET... je te conseillerais juste de ne jamais faire de certification de code temps réel. à part dans ce domaine, ce n'est pas très important

[alex_pi]

oui
si tu ne vois pas le rapport entre l'utilisation d'un GC et les problèmes de WCET... je te conseillerais juste de ne jamais faire de certification de code temps réel. à part dans ce domaine, ce n'est pas très important

Le problème est-il intrinsèquement lié à la notion de GC, ou au fait que la plupart des implémentations ne soient pas "real time proof" ? J'ai vu une présentation sur un GC temps réel pour Java, et ça avait l'air de plutôt bien marcher, non ? Après, je ne sais pas quels sont exactement les garanties avancées par les concepteurs du système. Mais effectivement, le temps réel est loin d'être mon domaine !

[gorgonite]

Le problème est-il intrinsèquement lié à la notion de GC, ou au fait que la plupart des implémentations ne soient pas "real time proof" ? J'ai vu une présentation sur un GC temps réel pour Java, et ça avait l'air de plutôt bien marcher, non ? Après, je ne sais pas quels sont exactement les garanties avancées par les concepteurs du système.

disons que si l'on n'est pas trop contraignant, le JIT et le GC peuvent passer... mais en gros, on aura une puissance de calcul nettement supérieure au besoin réel afin de s'assurer d'un délai correct de réponses dans le pire des cas. cela aura un cout en terme de consommation électrique, de dissipation thermique, etc

après si l'on doit vraiment faire petit, les GC ajoutent un offset dont on arrive à se passer grace à la gestion manuelle de la mémoire sur les softs utilisés en pratique (on ne fait pas tourner un ERP sur un micro-controleur, donc ça reste "simple")

en outre, je ne comprends vraiment pas pourquoi tant de personnes crachent sur la gestion manuelle à la C++ et tous ces types de pointeurs, qui permettent justement de faire bien plus fiable d'un GC avec compteur de référence, et bien plus performant qu'un GC moderne

[alex_pi]

disons que si l'on n'est pas trop contraignant, le JIT et le GC peuvent passer... mais en gros, on aura une puissance de calcul nettement supérieure au besoin réel afin de s'assurer d'un délai correct de réponses dans le pire des cas. cela aura un cout en terme de consommation électrique, de dissipation thermique, etc

après si l'on doit vraiment faire petit, les GC ajoutent un offset dont on arrive à se passer grace à la gestion manuelle de la mémoire sur les softs utilisés en pratique (on ne fait pas tourner un ERP sur un micro-controleur, donc ça reste "simple")

Encore une fois, ce n'est pas mon domaine, donc je raconte sans doute des conneries mais : si on est dans un domaine temps réel critique (tu parlais de certification, on ne fait sans doute pas ça pour les jeux vidéos ), on ne va pas de toutes manière exiger une forme de vérification statique de la quantité maximale de ressources allouées à un moment donné ? Au quel cas le problème se pose dans des termes franchement différents, non ?

en outre, je ne comprends vraiment pas pourquoi tant de personnes crachent sur la gestion manuelle à la C++ et tous ces types de pointeurs, qui permettent justement de faire bien plus fiable d'un GC avec compteur de référence, et bien plus performant qu'un GC moderne

Plus fiable qu'un compteur de référence, ça, ce n'est pas dur :-)
En revanche, "bien plus performant qu'un GC moderne", tu sors ça d'où? Il y a des tests fiable à ce sujet là ? Je me permets de me méfier de ce genre de phrase parce que ça sent un peu le "il faut écrire en assembleur parce que c'est bien meilleurs que le code produit par un compilo".
Ensuite, un GC est un morceau de code très complexe, donc sujet à des erreurs, je ne dirai pas le contraire. Mais j'avoue avoir plus confiance en la qualité de ce morceau de code testé par des milliers (dans le cas de OCaml) ou des millions (dans le cas de Java) d'utilisateurs qu'en la qualité de la gestion manuelle spécifique à telle ou telle application. Je veux bien croire qu'un excellent programmeur parfaitement talentueux pourra obtenir un meilleur résultat avec une gestion manuelle de la mémoire (et encore...), mais pour le commun des mortels, j'ai de sérieux doutes. Il n'y a qu'à voir le nombre de programmes souffrant de fuite de mémoire ou encore la quantité de temps passé par certains à lire des résultats de Valgrind avant d'obtenir un programme correct. Et si on me répond "ce ne sont pas de bons programmeurs", peut être qu'il faut se faire une raison : on manque de "bons" programmeurs par rapport aux besoins informatiques, donc trouver des solutions pour permettre aux "moins bons" programmeurs de tout de même faire des programmes sûrs et fiables me semble être un but en soi.
De plus, un GC est capable de faire de la désallocation par bloc, un mark and sweep pour défragmenter la mémoire, du traitement générationnel, etc etc. qui me semblent bien lourd à faire à la main.

[gorgonite]

De plus, un GC est capable de faire de la désallocation par bloc, un mark and sweep pour défragmenter la mémoire, du traitement générationnel, etc etc. qui me semblent bien lourd à faire à la main.

mais si on gère à la main, on a rarement besoin d'avoir des choses aussi lourdes

[alex_pi]

mais si on gère à la main, on a rarement besoin d'avoir des choses aussi lourdes

Ici, ce sont des optimisations, pas des besoins

Mais on en revient un peu à ce que je disais tout à l'heure. Est ce qu'on n'a rarement besoin de ça parce que c'est intrinsèquement inutile ou parce que pour pouvoir gérer sa mémoire à la main on est bien obligé de se restreindre ? Que pour avoir une chance de comprendre ce qu'il se passe, il faut se priver d'un certain nombre de solutions potentiellement claires, élégantes, efficaces, rapides etc. ? Je parlais des structures avec partages (et il arrive qu'il y ait des cycles, donc les smarts pointers ne sont pas suffisant), mais on peut poser le même genre de questions avec les fermetures et les suspensions (faire du lazy et gérer sa mémoire à la main, miam..), ces petits bonheur de la programmation fonctionnelle.
Bien sûr il est possible de programmer sans GC, la preuve, on le fait depuis longtemps Mais n'est ce pas finalement qu'une contrainte inutile dans l'immense majorité des cas ?

[Luc Hermitte]

Parce que de nouveau tu n'as pas besoin de déterminisme sur les ressources encapsulées dans tes instances dont tu n'as plus besoin.

De mon point de vue, les GC (à la Java du moins) sont largement inférieurs au comptage de référence -- d'un autre côté, je n'ai pas de problème de cycles contrairement à toi visiblement (d'ailleurs, tu n'as jamais besoin de faire des RAZ de pointeurs pour aider ton GC à se dépatouiller de ses cycles ou pour améliorer le WCET probable ?)

[Furikawari]

De toute façon, ce n'est pas un débat quand on voit les arguments (tout le monde fait du temps réel tous les jours, c'est évident).

Quand les plus courageux se seront retroussés les manches et que C++ aura aussi sont GC (comme Stroustrup l'a suggéré soit dit en passant), tout le monde trouvera le GC génial.

[gorgonite]

De toute façon, ce n'est pas un débat quand on voit les arguments (tout le monde fait du temps réel tous les jours, c'est évident).

Quand les plus courageux se seront retroussés les manches et que C++ aura aussi sont GC (comme Stroustrup l'a suggéré soit dit en passant), tout le monde trouvera le GC génial.

vive l'ouverture d'esprit...


heureusement que l'informatique est l'un des rares domaines où les guerres de religion ne font pas de morts

[Furikawari]

Ah les attaques personnelles ...

[gorgonite]

Ah les attaques personnelles ...

d'un côté tu prends les gens de haut en leur disant qu'ils ne sont que des moutons qui ne comprennent rien, mais qui suivront ce qui se fera quoi qu'il arrive... mais d'un autre, tu ne supportes pas qu'on te prenne pour une sorte d'intégriste. va falloir revoir ton point de vue... car la tolérance n'est pas une notion à sens unique

[Furikawari]

Je n'ai pris personne de haut, je dis juste que les arguments que je vois ici n'en sont pas, ou alors que dans des cas très particuliers qui vous permette ensuite de justifier des généralités. Ce n'est pas ce que j'appelle un débat.

De plus, vus les progrès faits dans les GC, vus également la démocratisation des multicores, tous les langages à terme utiliseront des GC et ça ne dérangera plus du tout les intégristes d'aujourd'hui.

[Luc Hermitte]

Quand les plus courageux se seront retroussés les manches et que C++ aura aussi sont GC (comme Stroustrup l'a suggéré soit dit en passant), tout le monde trouvera le GC génial.

C'est bien plus qu'une question de courage.
Pour les curieux, le C++ en est là pour l'instant: http://open-std.org/jtc1/sc22/wg21/d...2008/n2670.htm

Et sur ce sujet, il y a des discussions pointues et interminables sur clc++m.

Quant aux arguments, cela fait longtemps que ce fil tourne en rond. Étrangement la seule vraie conclusion (There is no Silver bullet) tarde à être reconnue.

[gorgonite]

De plus, vus les progrès faits dans les GC, vus également la démocratisation des multicores, tous les langages à terme utiliseront des GC et ça ne dérangera plus du tout les intégristes d'aujourd'hui.

le hic est que ce n'est pas parce que tu vois le multi-core et les 4 Go de Ram sur ton PC, qu'ils sont sur le point d'arriver dans tous les secteurs... et il faut savoir quand éviter de gaspiller son temps, quand adapter ce qui a été développé et testé depuis des dizaines d'années, etc
en bref, quand être pragmatique, et se dire que le progrès c'est bien... mais que chacun doit le faire à son rythme

[alex_pi]

Parce que de nouveau tu n'as pas besoin de déterminisme sur les ressources encapsulées dans tes instances dont tu n'as plus besoin.

Je ne suis pas sûr de saisir. Si tu as besoin de déterminisme, c'est a priori que tu sais exactement quand la dernière instance de ton objet finira d'être utilisé non ? Au quel cas tu dois pouvoir appeler manuellement (dans ce cas ;-)) la fonction adéquate, non ? Et si la seule contrainte c'est "une fois la dernière instance perdue", dans quel cas le fait que ce soit "après" mais pas forcément "juste après" est problématique ? Tu as un exemple concret ?

Soyons honnête, ce que je dis pour la gestion manuelle de la mémoire va aussi dans l'autre sens. Quand on ne la gère jamais à la main, on met en place des méthodes potentiellement contraignantes et non naturelle pour faire différemment et plus lourdement ce qui serait trivial en gestion manuelle (comme la libération de certaines ressources naturellement liées à un objet). Ca ressemble d'ailleurs probablement aux méthodes mis en place pour la gestion de la mémoire. Mais pour prêcher pour ma paroisse, disons que c'est peut être plus local (uniquement pour les ouvertures de fichiers par exemple, ou les connexions réseau, pas pour tout :-))

De mon point de vue, les GC (à la Java du moins) sont largement inférieurs au comptage de référence

Tu peux détailler ? Il me semble que ce que récupère un compteur de référence, un GC le récupèrera aussi (puisque si rien ne pointe dessus, il est bien inaccessible !). Donc en quoi le GC est-il "inférieur" à tes yeux ? Utilisation proc, consommation mémoire, réactivité ?

-- d'un autre côté, je n'ai pas de problème de cycles contrairement à toi visiblement

Je n'ai pas forcément de problème spécifique avec les cycles :-) C'est juste que je suis assez intégriste :-D Et les solutions partielles me dérangent. Parce que le jour où il y a un cycle, il y a une fuite de mémoire particulièrement pénible à trouver

(d'ailleurs, tu n'as jamais besoin de faire des RAZ de pointeurs pour aider ton GC à se dépatouiller de ses cycles ou pour améliorer le WCET probable ?)

Je ne fais pas dutout de temps réel, donc le WCET, ce n'est clairement pas le GC qui le change dans mon cas, mais bien l'algo utilisé.

Pour ce qui est de la remise à zéro des pointeurs, je ne peux pas, j'utilise un langage qui ne fait pas ça :-) En OCaml, les variables ne le sont pas, et il n'y a pas de pointeur null ! Mais il me semble que le paradigme crée naturellement moins de "fuite de pointeur" (je n'ai évidement aucun chiffre à l'appui, ni même d'argument "formel", juste une sensation). La porté des variables est particulièrement bien définie, elles sont souvent locales à l'appel d'une fonction (ce qui en paradigme fonctionnel signifie qu'elles sont vraiment local puisque le corps d'une fonction est généralement plus petit que dans le cas d'un langage impératif), etc.

[alex_pi]

Ah les attaques personnelles ...

En même temps quand on dit que les gens qui n'utilisent pas un GC sont des débiles, il ne faut pas s'attendre à avancer bien vite... Surtout que je ne connais pas luc, mais pour gorgonite, je te rassure, il a de vague notion de ce qu'est un bon langage à GC :-)

[Alp]

De toute façon, ce n'est pas un débat quand on voit les arguments (tout le monde fait du temps réel tous les jours, c'est évident).

Quand les plus courageux se seront retroussés les manches et que C++ aura aussi sont GC (comme Stroustrup l'a suggéré soit dit en passant), tout le monde trouvera le GC génial.

Comme l'a dit Luc, y'a eu une longue discussion à ce sujet ! Voir plusieurs.
Toutefois, il a été décidé à la réunion du commité à Sophia-Antipolis en Juin dernier que le GC ne serait absolument pas d'actualité pour C++0x.

En plus, avec des pointeurs intelligents dans la bibliothèque standard, ça peut attendre.

Le comptage de référence et de manière plus générale les différents types de pointeurs intelligents, permettent mieux que le GC à moindre coût : le GC détruit les choses inutilisées un peu quand il veut et peut, de manière donc absolument non déterministe. Un smart pointer qui marche à compteur de références se détruira dès lors que plus personne ne se servira de lui. C'est déterministe. Il y a même des comportements plus personnalisés que ça... Voir pour ça les pointeurs intelligents de Boost ainsi que le modèle de pointeur intelligent de Loki, écrit pas Andrei Alexandrescu. Il est en fait paramétré par plusieurs politiques ce qui permet d'avoir un pointeur intelligent sur mesure pour notre besoin (puisqu'on peut nous même implémenter les politiques et les lui fournir).

Je ne peux donc que soutenir les arguments de Luc.