C++0x : le Draft final a été voté !

Je n'étais pas présent lors de sa discussion... Mais je pense qu'il était un peu naïf ;)

De mémoire, mes réflexions quand je l'avais lu, c'est que les remarques sont mal ciblées pour une discussion en comité C++ : Et s'adressent à la version C++98, et non à la target en cours, et considèrent certaines implémentations du langage, au lieu de s'adresser au langage lui même :

Par exemple, sur l'aspect allocateur, il y a déjà eu beaucoup de boulot pour C++0x (avec les scoped allocators, poussés en avant entre autre par Bloomberg). Je ne sais pas s'ils répondent au besoin EA, mais je crois qu'ils ne sont pas discutés dans le document correspondant. D'autres points sont liés à C++98, et sont déjà corrigés dans C++0x, du coup, le document apporte peu (sauf s'il disait que les corrections apportées posaient encore problème).

Une autre partie des problèmes annoncés est lié à la présence de mauvais compilateurs, ne respectant pas bien ou pas efficacement la norme. On peut imaginer que dans ce cas la réponse soit plutôt "faites pressions sur vos implémenteurs, plutôt que de vouloir contourner ça dans la bibliothèque".

Quels sont les points que tu considères les plus utiles dans EASTL ?

@GeantVert : Anthony Williams est aussi l'auteur de boost.thread en fait... Donc c'est en fait de là que tout est parti, quand le comité s'est intéressé à l'intégration de threads dans la SL, il a commencé à faire une implémentation. Pour la suite, cf le post de Loïc.

Citation:

---

Quels sont les points que tu considères les plus utiles dans EASTL ?

---

Ca fait un moment que je l'ai lu donc je ne me souviens pas de points spécifiques mais il est vrai que pas mal de points sont résolu par le nouveau standard, enfin il me semble (comme par exemple la guarantie de vector n'allouant rien si aucun élément n'a été créé).

Donc en fait c'est plutot que la plupart des points sont implicitement résolus par le nouveau starndard? Pour les allocateurs, je ne sais pas si les scoped alloctor résolvent bien les mêmes problèmes que ceux proposé par EASTL, j'ai vu peu de documents les décrivant à vrai dire donc j'en ai encore une idée assez floue.

Faudrait que je reparcours ce doc quand j'aurais le temps, avec mon point de vue actuel plus au fait de C++0x.

Citation:

---

Envoyé par Alp

@GeantVert : Anthony Williams est aussi l'auteur de boost.thread en fait... Donc c'est en fait de là que tout est parti, quand le comité s'est intéressé à l'intégration de threads dans la SL, il a commencé à faire une implémentation. Pour la suite, cf le post de Loïc.

---

Oui je suppose qu'il n'y a rien d'anormal à récolter les lauriers (ou de l'argent) quand on s'est autant impliqué. C'est de bonne guerre.

j'ai une petite question concernant cette future-ancienne-pas encore arrivée mise à jour du c++;

qu'en est il de l'export template, j'ai vaguement lu sur un blog que c'était purement et simplement retiré pour l'instant parce que personne ne l'utilisait.

- déjà est ce que c'est vrai? (concernant le bottage de cul de cette fonctionnalité)
- les compilateurs populaires ne l'ont jamais pris en charge (enfin à ma connaissance), comment peut on dire dans ce cas que personne ne l'utilise?

Citation:

---

- déjà est ce que c'est vrai? (concernant le bottage de cul de cette fonctionnalité)

---

A ce que je sache, oui.

Citation:

---

- les compilateurs populaires ne l'ont jamais pris en charge (enfin à ma connaissance), comment peut on dire dans ce cas que personne ne l'utilise?

---

Parceque ça ne résouds pas vraiment les problèmes de dépendances, contrairement à extern template qui aide un peu.


L'explication par Herb Sutter : http://anubis.dkuug.dk/jtc1/sc22/wg2...2003/n1426.pdf

ok merci

Citation:

---

Envoyé par Klaim

L'explication par Herb Sutter : http://anubis.dkuug.dk/jtc1/sc22/wg2...2003/n1426.pdf

---

Ce papier est pour le moins contesté. Voir par exemple

http://groups.google.com/group/fr.co...f6969a0001a245

mais il y a eu une discussion similaire sur clc++m à l'époque.

ouais donc on est pas sorti du sable ><

Citation:

---

Envoyé par stardeath

ouais donc on est pas sorti du sable ><

---

Explique toi.

export est supprime. Il n'y a jamais eu qu'un front-end a l'avoir implemente et tous les compilateurs utilisant ce front-end ne le supportait pas.

Ca n'empeche que le papier de Sutter de 2003 est a mon sens une mauvaise presentation d'export. C'est uniquement a charge avec des arguments parfois infondes. Et il n'est pas la raison pour laquelle export a ete supprime (a l'epoque export a ete conserve).

bah facile, on nous fait miroiter une fonctionnalité intéressante, les problèmes résultant sont pour moi courant en c++, ni plus ni moins, aucun fournisseur courant de compilateur n'a suivi ce point de la norme, et maintenant c'est supprimé, facile de se faire un avis sur la dite fonctionnalité.

pour moi, c'est un des nombreux points que j'attendais, je suis juste encore plus déçu par cette révision.

Et extern template?


Sinon de toutes façons tant qu'il n'y aura pas de changement sur le model de compilation, je vois mal comment il pourrait y avoir des améliorations drastiques sur les temps de compilation.

En recourant à des hacks comme les unity-builds ?

Reste que les compilos annoncent des grosses améliorations dans les compilations des templates depuis plusieurs versions -> cf les blogs des diverses équipes qui s'occupent de la chose/les release notes.

Citation:

---

Envoyé par Klaim

Et extern template?.

---

à moins que je dise une bêtise, extern et export n'ont pas vraiment la même utilité, le premier dit "n'instancie pas le template ici" et l'autre "la définition du template est ailleurs" (fredonnons tous ensemble le générique de X-Files :mouarf:)

Je voudrait télécharger le dernier draft N3290 de la norme mais il me demande un login et un mot de passe sur le site officiel.

Où puis-je le télécharger ?

Le 3290 est un document officiel destiné à être publié, il est interdit par les procédures ISO de le proposer librement au téléchargement.

Le 3291 contient les mêmes infos, avec juste des marques de révision internes et n'est qu'un document de travail...

Citation:

---

Envoyé par JolyLoic

Le 3290 est un document officiel destiné à être publié, il est interdit par les procédures ISO de le proposer librement au téléchargement.

Le 3291 contient les mêmes infos, avec juste des marques de révision internes et n'est qu'un document de travail...

---

C'est la même chose pour le 3291. Il faut aussi un login.

Oui j'ai remarqué qu'ils ont fermé l'accès récemment et viré les liens. Dans le doute j'avais fais plusieurs sauvegarde du document 3290. Envoie moi un mp et je te l'envoie par email.

Je trouve ça débile que des standards soient payants ou à distribution réduite. Et après on s'étonne que trop peu de gens les respectent...

Ce sont les fournisseurs de compilos qui ont à les respecter. Et eux financent déjà le processus. C'est là que c'est idiot dans la mesure où pas tant de personnes en dehors de ces groupes n'ont besoin de disposer de la norme.