[C++0x]Pas de concepts

**JolyLoic** · 20/07/2009, 02h19

Envoyé par Alp

Quelques détails supplémentaires sur le scheduling pour la publication de la norme (printemps 2010 apparemment désormais) : http://groups.google.com/group/comp....a6ec6ea97817f4

Pas vraiment. De mémoire (sachant que de toute façon, c'est quand même assez pifométrique) :
- Printemps 2010 : Draft envoyé pour commentaires aux différent pays membre de l'ISO
- Plus tard (2 réunion ? 3 ?) quand les commentaires auront tous trouvés des réponses : Final draft, pour commentaires + approbation
- Puis enfin standard.

A mon avis, 2012 est plus probable, même s'il y a des chances que le draft de 2010 soit assez proche de ce qu'il y aura au final pour qu'il commence à être implémenté (et c'est ça qui compte).

**ac_wingless** · 20/07/2009, 18h13

C'est une très grosse déception. Sans les concepts, nous sommes encore coincés pour des années avec les horreurs de métaprogrammation et autres astuces boosto-pédantes.
Malheureusement, cela veut dire que ce besoin réel du langage, incarné à la fois par les astuces horribles fleurissant depuis quelques années et par la tentative maintenant avortée de fournir un support par le langage, ne va pas être satisfait.

Je code trop peu maintenant pour avoir vraiment une opinion autorisée sur le fait de savoir si les concepts en l'état proposé étaient mieux ou pire que les élastiques actuels. Par contre, je pense que ces élastiques à la Alexandrescu, que le comité vient de décider de ne pas remplacer, si brillants qu'ils soient, sont néfastes dans la programmation de tous les jours, et leur pérennité maintenant assurée remet sévèrement en cause l'avenir du C++. Pas moins.

En effet, face aux évolutions rapides et pragmatiques des deux autres langages qui mangent le C++ aujourd'hui, nous allons nous retrouver figés avec un niveau de productivité et de fiabilité dangereusement faible comparativement. Dans mon équipe, je ne me voyais de toute façon pas continuer à tenter de formaliser ce besoin de concepts par les méthodes actuelles (je rencontre soit une résistance considérable, soit une perte de productivité mesurable due au fait que ces astuces sont trop peu maitrisées, encouragent l'élégance pour l'élégance, voire l'ésotérisme le plus dangereux). Que reste-t-il maintenant? Continuer sans même l'idée de concept, alors que la communauté entière a clairement montré son besoin sur maintenant près de dix ans?

Je comprends les hésitations sur graver dans le marbre une implémentation peu enthousiasmante. Par contre, le besoin était énorme, validé à la fois par les pléthores de hacks actuels et l'ampleur des efforts du comité sur ce sujet.

Quelles que soient les raisons de ce choix (peut-être le moins mauvais dans l'alternative à laquelle les votants étaient confrontés), le résultat est que ce besoin est ignoré. C'est plus que dommage, c'est inquiétant, ne serait-ce que parce que cela expose durement l'incapacité du comité à faire évoluer le C++ aussi bien et aussi vite que les langages propriétaires.

**Florian Goo** · 20/07/2009, 20h06

ac_wingless, ton message résume ma pensée et mes craintes à la perfection.
Peut-on espérer un retournement de situation si les réactions de ce genre viennent à se multiplier ?
Une reprogrammation des concepts pour, mettons, 2013 seraient vraiment un soulagement.

**JolyLoic** · 21/07/2009, 01h25

On peut espérer des efforts hors normalisation autour des concepts (peut-être même des efforts concurrents d'équipes concurrentes), qui se traduiraient peut-être dans des compilateurs utilisables. Mais officialisé et normalisé, j'y crois très peu pour ces dates là.

**Klaim** · 21/07/2009, 02h14

J'espère cela aussi, mais je vois mal comment on pourrait avoir une implementation portable vu les désaccords sur pas mal de détails et le peu de chances pour que les équipes de développement des différents compilateurs se mettent d'accord. A la limite si dans la pratique (si pratique il y a) ils se retrouvent avec les memes problemes et des solutions equivalentes, au moins le probleme aura été testé.

J'ai lu le document de Stroustrup sur ses simplifications pour aider a l'adoption des concepts. C'est très instructif aussi.

**koala01** · 21/07/2009, 04h41

Envoyé par Klaim

J'espère cela aussi, mais je vois mal comment on pourrait avoir une implementation portable vu les désaccords sur pas mal de détails et le peu de chances pour que les équipes de développement des différents compilateurs se mettent d'accord. A la limite si dans la pratique (si pratique il y a) ils se retrouvent avec les memes problemes et des solutions equivalentes, au moins le probleme aura été testé.

Eh bien, à la lecture du lien qui exprimait les différentes possibilités, on se rend compte que l'idée était à la base de pouvoir profiter du "feed-back" de certains projets les implémentant (tels que conceptGcc), mais que le problème venait justement que l'évolution de ces projets était plus ou moins "bloquée" et qu'il y avait peu d'espoirs de voir une équipe arriver à un résultat raisonnable avant... 20011...

L'article présentait une solution qui aurait consisté à donner les informations "théoriques" sur les concepts mais à ne pas en donner d'implémentation, justement, parce qu'il n'existe pas d'implémentation suffisamment stable pour se faire une idée des problèmes soulevés par leur forme actuelle (comprend : la forme qui était la leur avant qu'ils ne soient abandonnés)

Je comprend personnellement que cette solution n'était vraiment pas réalisable, simplement parce qu'il faut quand même être en mesure de s'assurer que la norme soit cohérente et puisse être mise en oeuvre

Ceci dit, cela fait plusieurs jours maintenant que je me pose la question de savoir s'il ne s'agit pas d'une certaine manière d'un "vote sanction" dont le but aurait été d'envoyer un signal fort aux deux parties intéressées leur indiquant qu'il serait tout doucement temps d'essayer d'arriver à un accord sur ce que doivent être les concepts

**ac_wingless** · 21/07/2009, 14h26

Envoyé par Klaim

J'ai lu le document de Stroustrup sur ses simplifications pour aider a l'adoption des concepts. C'est très instructif aussi.

Oui, c'est un document très intéressant. Voici un lien pour ceux que ça intéresse.

**Arzar** · 22/07/2009, 19h28

Un peu de surf sur l'onde de choc...

The Removal of Concepts From C++0x sur informIT.
The Removal of Concepts From C++0x sur artima.
The Rise and Fall of C++0x Concepts sur devx.
Concepts Get Voted Off The C++0x Island sur lambda-the-ultimate avec dans les commentaires une réaction de Jeremy Siek, l'un des co-auteurs de la proposition sur les concepts.
The C++0x "Remove Concepts" Decision sur Dr. Dobb par Bjarne Stroustrup.

**Klaim** · 23/07/2009, 01h50

Je n'ai pas lu tout en détail les spécifications des concepts (enfin, pas tout, mais une grande partie) et a ce qu'il me semble tout était censé se passer a la compilation, n'est-ce pas? ?

Or je lis (par exemple dans l'article de Stroustrup) qu'il y avait des inquiétude quand à la performance à l'execution...
De quoi parle-t-il? Ou est-ce juste une peur liée a l'implémentation de ConceptGCC?

**Jean-Marc.Bourguet** · 23/07/2009, 10h18

Envoyé par Klaim

Je n'ai pas lu tout en détail les spécifications des concepts (enfin, pas tout, mais une grande partie) et a ce qu'il me semble tout était censé se passer a la compilation, n'est-ce pas? ?

Oui.

Or je lis (par exemple dans l'article de Stroustrup) qu'il y avait des inquiétude quand à la performance à l'execution...
De quoi parle-t-il?

A ma connaissance, principalement des pénalités d'abstraction (abstraction penality). A force de mettre des petits wrappers partout (les concepts maps, même implicites, même triviaux ne sont pas autre chose), le compilateur pourrait ne pas s'en tirer et ne pas inliner des choses qu'il serait possible en théorie d'inliner. Note que le problème existe aussi avec la POO.

Ou est-ce juste une peur liée a l'implémentation de ConceptGCC?

D'après ce que j'ai compris -- j'ai pas fait d'expérimentations personnelles là dessus --, ConceptGCC montre justement qu'il y a moyen de s'en sortir à un coût raisonnable.

Les craintes posées par ConcepGCC sont plus du ressort du temps de compilation (à noter que malgré toutes leurs divisions, ces craintes ne sont pas partagées par les partisans des concepts).

**Klaim** · 23/07/2009, 10h40

Ok je vois maintenant, merci.

Pour les doutes sur le temps de compilation j'imagine que c'était un peu pareil quand les templates ont été proposés.

**Jean-Marc.Bourguet** · 23/07/2009, 10h45

Envoyé par Klaim

Pour les doutes sur le temps de compilation j'imagine que c'était un peu pareil quand les templates ont été proposés.

J'étais pas là :-) Mais note que les templates ont été introduits avant que le processus de standardisation ne commence.

**Florian Goo** · 23/07/2009, 11h11

http://www.devx.com/cplus/Article/42365/0/page/2

Envoyé par Danny Kalev

What Next?

At this stage, no one really knows how difficult (and dangerous) the removal of concepts will be. Rewriting every piece of code and sentence that refer to concepts will be a painstaking process. Yet the main problem here isn't just editorial. In the past five years C++0x has pretended that concepts are a done deal. Therefore, every phrase in "conceptese" will have to be rephrased in plain English. To illustrate the extent of this problem, consider article 30.3.1/3 of the CD:

"A Mutex type shall be DefaultConstructible and Destructible. […] A Mutex type shall not be copyable nor movable."

These two sentences alone reference four different concepts! And the CD contains 1,340 pages of text, charts and code.

Ne pourraient-ils pas laisser ces phrases telles quelles et exprimer les concepts de façon informelle ?
Quand on regarde la référence STL du SGI, on peut voir que les concepts font clairement partie du lot, alors qu'ils ne font pas partie du langage lui-même. Par exemple, le concept Assignable est défini ainsi : http://www.sgi.com/tech/stl/Assignable.html

Ce sera autant de pas en arrière évités et ça permettra peut-être à quelques features dépendantes des concepts de ne pas sauter.

En plus, ça inciterait les vendors à implémenter la partie interne des concepts (celle qui est « stable »). Ce serait un début.

Envoyé par Danny Kalev

Furthermore, they insist that the outward complexity of concepts is misleading—the underlying model is "good enough;" it's only the surface complexity (what the user has to write) that needs fixing.

Qu'en pensez-vous ?

**Klaim** · 23/07/2009, 12h18

Herb Sutter en a aussi parlé mais pour lui ce n'est pas si dramatique : http://herbsutter.wordpress.com/2009/07/21/trip-report/

Notamment concernant le boulot de réécriture du draft:

Q: Isn’t removing concepts a lot of work? Concepts are used pervasively in the C++0x CD published last fall.

A: Yes, but it’s less work than you’d think. We won’t have a de-conceptized working draft for the post-meeting mailing, two weeks after the meeting, but should have one soon after that. (I would be remiss not to add: Thanks to our always-hardworking project editor, Pete Becker!)

Recall that, until last September, we had a complete draft of C++0x features specified entirely without the use of concepts. And many of the uses of concepts in the draft standard library were just replacements of preexisting non-concepts wording or implicit requirements (e.g., DefaultConstructible, MemberContainer), and will just revert to their previous wording or disappear back into implicitness.

The main C++0x feature that was always specified in terms of concepts was the new range-based for loop (e.g., for( x : collection ) ). I’ve seen some wonder what we’ll do about that, but it’s already done; the non-concepts text for that feature was already voted in at the same Frankfurt meeting.

**loufoque** · 27/07/2009, 13h41

C'est bien qu'ils aient viré les concepts. Ce n'était pas *si* utile que ça (on peut faire des choses équivalentes avec des syntaxes similaires) et cela redonne une chance à de nouvelles fonctionnalités qui avaient été écartées faute de temps, comme les lambdas polymorphiques.

**Alp** · 27/07/2009, 13h45

Envoyé par loufoque

comme les lambdas polymorphiques.

Ils ont attaqué ?
Source ?

**Florian Goo** · 27/07/2009, 19h37

@loufoque
À ce propos j'ai lu (et répondu à) ton commentaire…
Si tu arrives réellement à une syntaxe tout aussi expressive, alors j'ai vraiment raté quelque chose…

**JolyLoic** · 27/07/2009, 22h27

Envoyé par loufoque

C'est bien qu'ils aient viré les concepts. Ce n'était pas *si* utile que ça (on peut faire des choses équivalentes avec des syntaxes similaires) et cela redonne une chance à de nouvelles fonctionnalités qui avaient été écartées faute de temps, comme les lambdas polymorphiques.

Je ne pense pas qu'une telle fonctionnalité soit à l'ordre du jour. Le but est de tout boucler au plus vite

**loufoque** · 28/07/2009, 03h54

Si tu arrives réellement à une syntaxe tout aussi expressive, alors j'ai vraiment raté quelque chose…

Même syntaxe que Boost.ConceptCheck par exemple.
Le plus, c'est qu'avec SFINAE étendu aux expressions, on peut maintenant donner une réponse oui/non à la compilation à si un type modélise un concept, et éventuellement l'utiliser pour la surcharge. (sans SFINAE pour les expressions, c'est juste oui ou erreur).