Discussion :

[Le Farfadet Spatial]

Salut à tous !

Au delà des discussions sur la bonne architecture à donner à un code, permettez-moi de revenir au sujet initial, plus ou moins : j'ai eu un peu de mal à suivre, où en est le processus de ratification de C++0x à l'heure actuelle (avril 2008) ? 2009 est-elle toujours la date envisagée pour la sortie du nouveau standard ?

À bientôt.

Le Farfadet Spatial

[Alp]

2009 semble difficile. Mais il y a une réunion du commité en Juin 2008 à Sophia-Antipolis près de Nice ! On en saura plus après cette réunion. L'évènement est normalement couvert par un membre de l'équipe C++ de Developpez. Grâce à lui nous pourrons ainsi en savoir plus

[Le Farfadet Spatial]

Salut à tous !

2009 semble difficile.

Ah ! C'est ce que j'avais cru comprendre. Faut-il désormais parler de C++xx ?

Mais il y a une réunion du commité en Juin 2008 à Sophia-Antipolis près de Nice !

Ça, j'avais zappé. Bon, il faut que je trouve un moyen de justifier auprès de mon labo un petit voyage à Sophia-Antipolis...

L'évènement est normalement couvert par un membre de l'équipe C++ de Developpez. Grâce à lui nous pourrons ainsi en savoir plus

Formidable !

À bientôt.

Le Farfadet Spatial

[loufoque]

Ça, j'avais zappé. Bon, il faut que je trouve un moyen de justifier auprès de mon labo un petit voyage à Sophia-Antipolis...

Il faut être invité par un membre du comité pour y assister, il me semble, et bien sûr faut avoir des commentaires constructifs à faire.

[Alp]

Non il ne faut pas être invité. Il faut appeler la secrétaire de cette réunion, réserver une chambre à l'hôtel et c'est bon.

[Emmanuel Deloget]

2009 semble difficile. Mais il y a une réunion du commité en Juin 2008 à Sophia-Antipolis près de Nice ! On en saura plus après cette réunion. L'évènement est normalement couvert par un membre de l'équipe C++ de Developpez. Grâce à lui nous pourrons ainsi en savoir plus

2009 me semble parfaitement tenable. Si ma mémoire est bonne, après la réunion de Nice, il n'est plus prévu d'ajouter quoi que ce soit dans le standard - seulement de l'affiner et de le corriger. Il restera donc plusieurs mois pour trouver un wording convenable avant la sortie, prévue pour fin 2009.

Ca devrait tenir

[Alp]

Ah. Il est possible que tu ais raison. J'avais seulement lu je ne sais où que le commité voulait sortir C++09, mais que rien n'était garanti. Tu aurais un lien ?

[Luc Hermitte]

Au delà des discussions sur la bonne architecture à donner à un code, permettez-moi de revenir au sujet initial, plus ou moins : j'ai eu un peu de mal à suivre, où en est le processus de ratification de C++0x à l'heure actuelle (avril 2008) ?

Suffit de demander. http://herbsutter.wordpress.com/2008...o-c-evolution/

[Le Farfadet Spatial]

Salut à tous !

Merci Luc, voilà qui répond exactement à ma question.

À bientôt.

Le Farfadet Spatial

[catstevens01]

merci pour ce topic fort interessant
je veux juste savoir si en c++ on ne cherche pas a mettre en place un ramasse miette comme le fait managed c++ qui profite du clr et ramasse miette du dotnet ou le java

[JolyLoic]

Une discussion a eu lieu dans le comité C++ pour introduire un garbage collector dans le standard. Cette discussion n'a finalement pas donnée grand'chose.

Aujourd'hui, ce qui est prévu, c'est uniquement quelques modifications du langage afin de faciliter l'intégration d'un garbage collector externe.

Un certain nombre de personnes étaient contre le garbage collector, d'après ce que j'ai pu en voir, les arguments étaient (je ne dis pas si je suis ou pas d'accord avec) :
- Sans finalizer, le GC n'est pas forcément hyper utile, et avec finalizers, c'est complexe, tordu, source de problèmes...
- On a en C++ d'autre mécanismes, qui font que le GC n'est pas forcément indispensable
- Comment se marient des bibliothèque prévues pour un GC et d'autres prévues sans GC dans une même application ?
- On n'a pas le temps de mettre un GC maintenant dans le langage, c'est trop gros et trop tard.

[loufoque]

La solution pour intégrer un ramasse-miettes de manière transparente c'est de baser son code sur le RAII et de désactiver les destructeurs quand celui-ci est activé.
Comme ça on peut pouvoir bénéficier, avec une option, d'une libération globale de tous les objets morts à la place de libérations incrémentales, ce qui peut être plus performant.

(Je parle de ramasse-miettes en général, pas forcément dans le cadre de la mémoire)

On pourra donc remarquer que du coup il n'y pas à faire d'analyse de "reachabilité", et que le code est tellement trivial qu'il n'y a pas besoin de support dans le compilateur pour cela.

[JolyLoic]

Si j'ai bien compris ce que tu veux dire, il ne s'agit pas du tout de ramasse miette, mais uniquement d'une optimisation de la libération de la mémoire.

[Klaim]

D'après Wikipedia :

Transparent garbage collection

C++0x will not feature transparent garbage collection directly. Instead, the C++0x standard will include features that will make it easier to implement garbage collection in C++.

Full garbage collection support has been remanded to a later version of the standard or a Technical Report.

Donc en gros ils comptent revoir tout ça pour le TR2, et voir si les modifications apportées par le nouveau standard va aider a mettre ça en place (ou le rendre moins utile?).

Au fait, j'ai tendance a suivre l'evolution du standard en vérifiant "régulièrement" cette page wikipedia. Je suis pas sur que ce soit la meilleure source mais ça a l'air d'être le meilleur résumé a priori (plus digestes que les centaines de docs officielles du moins).

[Alp]

Le meilleur endroit c'est le site du commité lui-même, où tu peux suivre l'évolution du draft et des discussions avant et après chaque meeting du commité : http://www.open-std.org/jtc1/sc22/wg21/

[Klaim]

C'est justement ce que je qualifie "d'indigeste" (je suis aussi ces docs pour la plupart)

Mais en fait c'est plutot que c'est pas très synthétique (forcément puisque tout les points sont séparés dans des docs séparés et souvent long a lire).
Habituellement je passe quelques heures sur les sujets qui m'intéressent le plus mais je n'ai pas le temps de toute lire (pourtant je lis énormément de docs du genre!).
Si vous avez d'autres pages avec des infos plus synthétiques sur ce qu'il se passe, je suis preneur.

[JolyLoic]

Ce qu'il y a sur wikipedia n'est pas forcément hyper à jour ni hyper détailé. En l'occurence, j'ai peur que les réticences qu'ont certains face au GC ne s'effacent pas comme par magie au moment d'un TR, et que repousser le GC dans un TR est pour eux une manière de l'enterrer.

Parmi les documents indiqués par Alp, il y en a 2, remis à jour avant et après chaque réunion par Alisdair Meredith, qui sont assez synthétiques :
State of C++ Evolution
C++ Library Working Group Status Report

[loufoque]

Si j'ai bien compris ce que tu veux dire, il ne s'agit pas du tout de ramasse miette, mais uniquement d'une optimisation de la libération de la mémoire.

Le principe d'un ramasse-miettes c'est qu'au lieu de libérer un "bloc" dès qu'on a finit de s'en servir, on fait de temps en temps une analyse complète de l'ensemble des blocs en collectant tous les "blocs" morts.
La "reachability analysis", n'est qu'une manière parmi d'autre de déterminer ce qui est vivant ou non, qui a l'avantage d'être automatique. Elle est la plus populaire, et est souvent synonyme de ramasse-miettes même si ce n'est qu'un cas particulier.
On peut aussi très bien se baser sur des méta-informations propres au "bloc". Si on utilise du RAII, on peut avoir tout simplement un bit qui dit si c'est vivant ou non (ce qui est équivalent à mark and sweep sans le mark). On peut aussi imaginer d'autres mécanismes, comme par exemple stocker la dernière date d'utilisation et libérer après une certaine durée (c'est ce genre de chose qui est utilisé pour implémenter les sessions dans les applications web).

[JolyLoic]

Le principe d'un ramasse-miettes c'est qu'au lieu de libérer un "bloc" dès qu'on a finit de s'en servir, on fait de temps en temps une analyse complète de l'ensemble des blocs en collectant tous les "blocs" morts.

Il semble que ce soit là que nos avis divergent. Pour toi, la caractéristique principale du ramasse miette semble être la désallocation asynchrone de la mémoire, la détection automatique de ce qu'il y a à allouer n'étant qu'un détail d'une des façons possible d'y parvenir.

Pour moi, le ramasse miette a comme raison d'être principal de libérer le développeur de la tâche consistant à gérer la désallocation mémoire. Le fait que du coup cette désallocation se fasse de manière globale et asynchrone n'est pour moi qu'un détail technique (souvent malheureux, d'ailleurs) de l'implémentation.

[Jean-Marc.Bourguet]

Il semble que ce soit là que nos avis divergent. Pour toi, la caractéristique principale du ramasse miette semble être la désallocation asynchrone de la mémoire, la détection automatique de ce qu'il y a à allouer n'étant qu'un détail d'une des façons possible d'y parvenir.

s/allouer/désallouer/ je suppose.

Pour moi, le ramasse miette a comme raison d'être principal de libérer le développeur de la tâche consistant à gérer la désallocation mémoire. Le fait que du coup cette désallocation se fasse de manière globale et asynchrone n'est pour moi qu'un détail technique (souvent malheureux, d'ailleurs) de l'implémentation.

De même, et le cas où c'est particulièrement intéressant, c'est le cas des dépendances circulaires.