Discussion :

[JolyLoic]

Bonjour,

Le vote a eu lieu aujourd'hui, et la décision a été prise de ne pas inclure les concepts dans C++0x. Les principaux arguments étaient que beaucoup d'acteurs estimaient que la proposition n'était pas assez mature, et risquait de repousser le standard.

Nous n'avons pas encore décidé comment le travail sur les concepts doit continuer, et quand ils pourront être intégrés dans le langage.

[hiura]

Pour les ignorants comme moi, aurais-tu un lien de ce que sont les concepts ?

[Goten]

En gros ça permet de définir une interface que doit fournir un paramètre de template.
Ca permet en premier lieu d'avoir des erreurs du compilo plus direct, par exemple si t'essayes de stocker dans un vecteur un objet qui n'est pas copi-able.

Ca aurait permis d'écrire ce genre de chose :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
template <typename T> requires equalityComparable<T>
bool isEqual(const T& lhs, const T& rhs)
{
     return lhs==rhs;
}
 
// et on définit un concept comme ceci :
 
auto concept equalityComparable<typename T>
{
    bool operator==(const T&);
}

Désolé pour la pauvreté de l'exemple mais j'ai pas mieux en tête xD. D'ailleurs je suis pas sur de l'exactitude de la syntaxe du concept (au niveau de la définition de l'opérateur)


J'ai pas de lien très poussé sous la main, jte retrouve ça.

[JolyLoic]

Un des exemples fondateurs est std::sort. Si tu fais std::sort sur des itérateurs de std::list, tu auras un message d'erreur obscur qui parlera peut-être d'un problème avec un opérateur [] ou un opérateur + dans du code qui n'est pas à toi, mais fait partie de la bibliothèque standard.

Avec des concepts, tu aurais eu une erreur dans ton code, indiquant que sort a besoin d'itérateurs à accès direct (RandomAccessIterator), et que tu lui as fourni des itérateurs d'un mauvais type.

Le but étant de rendre les messages d'erreur des templates compréhensibles par le commun des mortels.

Et ils permettaient aussi bien d'autres choses, entre autre une bonne gestion de l'overloading des templates, ce qui aujourd'hui doit se faire à la main avec des astuces et des classes de traits. Avec les concepts, les classes de traits auraient probablement disparu peu à peu.

[hiura]

D'accord, merci à vous deux.

Je crois en fait que j'en avais déjà entendu parler. N'y avait-il pas l'intention d'introduire le mot clef where ?

[3DArchi]

Bonjour,
Effectivement, c'est dommage.
Entre autres, les concepts :
-> jouent le rôle des classes traits : ils spécifient les exigences qu'un paramètre d'une classe/fonction template doit remplir (le code suivant ne suit pas la syntaxe exacte proposée mais illustre le propos ):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
// définition d'un concept :
concept Comparable<typename T> {
bool operator<(T, T);
   // On spécifique qu'il doit exister un opérateur '<' de la forme indiquée ci-dessus.
}
 
// utilisation dans une fonction template :
template<class T>
   requires Comparable<T>
T min(T t1, T T2)
{...

_> jouent un peu le rôle des classes politiques avec les concept map : les concepts map permettent de dire comment un concept (un 'require') est rempli par une classe dans le cas où l'exigence n'est pas immédiate :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
class personne {
public:
std::string nom;
std::string prénom;
};
 
concept Comparable<typename T> {
bool operator<(T, T);
}
 
concept_map Comparable<personne > { 
// ca ne définit pas un opérateur '<' sur la classe personne
// mais ça indique comment l'exigence doit être remplie
bool operator<(const personne& a, const personne& b) {
return (a.nom == b.nom) ?(
    (a.prénom == b.prénom)?
        false
        : (a.prénom< b.prénom))
    : (a.nom < b.nom)
;
}

Tu peux trouver des infos sur les concepts ici , ici ou là

[Alp]

C'est bien dommage

Qui plus est, j'avais commencé un article dessus

[Goten]

C'est "qu'un" article (pas péjoratif du tout hein), quand je pense au petit gars des compilo qui implémentait déjà cette feature, les glandes :p.

[Alp]

C'est "qu'un" article (pas péjoratif du tout hein), quand je pense au petit gars des compilo qui implémentait déjà cette feature, les glandes :p.

Oui, Doug Gregor doit avoir du mal à digérer ça, il était derrière Concept GCC, et les concepts en général je crois.

[hiura]

Merci pour les liens.

De mon point de vue "utilisateur", c'est vrai que je suis déçu que ça soit repoussé au prochain std, mais en même temps je préfère ça à un ajournement du 0x.

Pour le travail de Doug Gregor, n'y a-t-il pas un "plan" de prévu ? ( Du style une version de gcc qui accepte les concepts ? )

[Alp]

Hé bien : http://www.generic-programming.org/software/ConceptGCC/
qui devient (devenait ?) : http://gcc.gnu.org/svn/gcc/branches/...ncepts-branch/ (branche pour les concepts de gcc)

Plus d'infos sur http://www.generic-programming.org/ et http://gcc.gnu.org/projects/cxx0x.html#concepts

[Jean-Marc.Bourguet]

Effectivement, c'est dommage.

S'il y a des alternatives que j'aurais preferees, il y en a d'autres que
je craignais. Je ne suis pas sur que ce soit dommage, car je suis loin
d'etre sur que celles que j'aurais preferefees soient en fait viables.

Oui, Doug Gregor doit avoir du mal à digérer ça,

Loic doit pouvoir commenter mieux que moi sa reaction.

il était derrière Concept GCC,

Oui.

et les concepts en général je crois.

Oui, mais c'est loin d'etre le seul. J'aurais a citer un seul nom pour
etre "derriere les concepts en general", je dirais A. Stepanov. Mais je
connais tres mal ce qui est en rapport avec d'autres langages (si quelqu'un
veut faire des recherches, de memoire Axiom, OpenAxiom, Aldor sont des
mots-cles a utiliser).

De mon point de vue "utilisateur", c'est vrai que je
suis déçu que ça soit repoussé au prochain std, mais en même temps je
préfère ça à un ajournement du 0x.

Je doute que les concepts en l'etat ait ete utile a quelqu'un qui ne sait
d'eux que ce qui a ete ecrit ici sans un gros travail de
comprehension, meme comme simple utilisateur de bibliotheques utilisant les
concepts.

Pour le travail de Doug Gregor, n'y a-t-il pas un "plan" de prévu ?
(Du style une version de gcc qui accepte les concepts ?)

ConceptGCC est disponible:
http://www.generic-programming.org/software/ConceptGCC/ mais ce n'est plus
maintenu depuis un an. Et ca ne correspond meme pas aux concepts tels
qu'ils etaient proposes alors. Ma comprehension est qu'il n'y avait pas de
plan d'integrer conceptGCC tel quel dans GCC.

[hiura]

Je doute que les concepts en l'etat ait ete utile a quelqu'un qui ne sait
d'eux que ce qui a ete ecrit ici sans un gros travail de
comprehension, meme comme simple utilisateur de bibliotheques utilisant les
concepts.

Ben il faut bien en entendre parler à un moment où un autre pour pouvoir s'y intéresser et approfondir le sujet.
( Et avec tous les liens qui sont donnés on peut vite se forger une idée du sujet. )

[JolyLoic]

Oui, Doug Gregor doit avoir du mal à digérer ça, il était derrière Concept GCC, et les concepts en général je crois.

J'ai un peu l'impression qu'il en avait déjà fait son deuil avant même la réunion. Bjarne m'avait l'air plus affecté, il était lui aussi derrière ça depuis le début.

Oui, mais c'est loin d'etre le seul. J'aurais a citer un seul nom pour
etre "derriere les concepts en general", je dirais A. Stepanov. Mais je
connais tres mal ce qui est en rapport avec d'autres langages (si quelqu'un
veut faire des recherches, de memoire Axiom, OpenAxiom, Aldor sont des
mots-cles a utiliser).

Dans le cadre purement C++, il y avait principalement deux équipes à l'origine sur le sujet, d'un côté Bjarne Stroustrup et Gaby Dos Reis, de l'autre Doug Gregor et Jeremie Siek. Plus plein d'autres contributeurs (James Widman, par exemple), plus tous ceux qui ont travailler sur l'application des concepts à la bibliothèque standard.
La présence de deux sources différentes de proposition, qui n'ont jamais réussi à vraiment être mergées, et avec des philosophies un peu différentes est certainement une des causes de retard.

Je doute que les concepts en l'etat ait ete utile a quelqu'un qui ne sait
d'eux que ce qui a ete ecrit ici sans un gros travail de
comprehension, meme comme simple utilisateur de bibliotheques utilisant les
concepts.

C'était un des problèmes principaux : En l'état, les concepts étaient compliqués à comprendre. Et pas uniquement pour les développeurs de bbliothèque, mais peut être aussi pour leurs utilisateurs. Ce qui pour une fonctionnalité destinée à simplifier l'utilisation des templates pourrait sembler paradoxal.

ConceptGCC est disponible:
http://www.generic-programming.org/software/ConceptGCC/ mais ce n'est plus
maintenu depuis un an. Et ca ne correspond meme pas aux concepts tels
qu'ils etaient proposes alors. Ma comprehension est qu'il n'y avait pas de
plan d'integrer conceptGCC tel quel dans GCC.

De plus, d'après Doug, les choix de design effectués pour sortir conceptGCC rapidement devraient profondément évoluer pour obtenir une version utilisable (conceptGcc est actuellement calamiteux en temps de compilation). Et il n'est pas sur que ça n'aurait pas demandé aussi un redesign de gcc lui même.

Pour le travail de Doug Gregor, n'y a-t-il pas un "plan" de prévu ? ( Du style une version de gcc qui accepte les concepts ? )

Je vous tiendrai au courant dès que j'aurai vent de plans de travails pour continuer à faire avancer les concepts.

[Jean-Marc.Bourguet]

Ben il faut bien en entendre parler à un moment où un autre pour pouvoir s'y intéresser et approfondir le sujet.

C'etait pas une critique de ton commentaire mais plutot de l'etat des concepts. On est beaucoup trop dans le "il n'y a pas de problemes evidents" plutot que dans le "il est evident qu'il n'y a pas de problemes" que toute conception doit viser.

[hiura]

Je vous tiendrai au courant dès que j'aurai vent de plans de travails pour continuer à faire avancer les concepts.

Merci.

C'etait pas une critique de ton commentaire mais plutot de l'etat des concepts.

Ha, ok. J'avais compris bien autre chose moa ( que c'était au dessus du niveau de l'amateur ) .

[Jean-Marc.Bourguet]

( que c'était au dessus du niveau de l'amateur ) .

C'est un peu l'idee. Je ne jette la pierre ni a l'amateur, ni a l'idee sous-jacente aux concepts, mais a sa realisation.

[Arzar]

Bjarne m'avait l'air plus affecté, il était lui aussi derrière ça depuis le début.

Hum, ça ne m'étonne pas trop. Quand on voit la conclusion de son proposal de juin pour simplifier l'utilisation des concepts...

The use of concepts is supposed to help people write and use a wide range of templates. The current definition of concept maps and the philosophy that seems to go with them makes it harder.

Addressing this is important. I suspect that the alternative is widespread disuse of concepts and libraries using concepts. I would consider that a major failure of C++0x.

Sacré coup de massue.

Avec un peu de recul, j'ai l'impression que les concepts était une tentative un peu eu... héroique/courageuse/téméraire/folle/désespéré ? pour revitaliser le langage et surtout renouveler l'exploit qu'a déjà fait le C++ dans les années 90 en faisant glisser la programmation objet vers le mainstream, mais cette fois pour la programmation générique.

Hiura, sans rentrer dans les détails, la promesse des concepts c'était de simplifier l'utilisation des templates, d'éradiquer les messages d'erreurs de trois kilomètres et de balayer la montagne de hack horripilant (classe de traits, metaprogrammation...) qui règne à l'heure actuelle sur la programmation générique. Le but était qu'un programmeur C++ moyen puisse écrire des concepts et des fonctions génériques de temps en temps, de la même façon que tout programmeur C++ moyen écrit des classes mères et utilise le polymorphisme de temps en temps.

Mais bon, au vu de :

C'était un des problèmes principaux : En l'état, les concepts étaient compliqués à comprendre. Et pas uniquement pour les développeurs de bbliothèque, mais peut être aussi pour leurs utilisateurs. Ce qui pour une fonctionnalité destinée à simplifier l'utilisation des templates pourrait sembler paradoxal.

Ca a l'air d'avoir mechamment mal tourné quand même.

Je vous tiendrai au courant dès que j'aurai vent de plans de travails pour continuer à faire avancer les concepts.

Merci.
En effet, que va-il se passer très concrètement maintenant ? Vu que les concepts serpentent partout dans le draft actuel, une "déconceptualisation" va prendre une energie considérable, non ?

Si tu as d'autre infos croustillantes, n'hésite pas Loic ! Moi, je grouille d'impatience de voir ce qui va sortir du meeting de cette semaine. Avec la fin de la décennie qui approche, la fenêtre de tir pour la standardisation ISO se referme petit à petit et le comité va devoir prendre des décisions de plus en plus radicale pour terminer à temps. Et vu l'avalanche de proposal dans le mailing de juin, il y a clairement du pain sur la planche

[hiura]

Avec un peu de recul, j'ai l'impression que les concepts était une tentative un peu eu... héroique/courageuse/téméraire/folle/désespéré ?

intéressante ?
Qu'est-ce qui change avec le recul ? C'était une tache trop grosse ? ( Je sais que je ne suis qu'un amateur ( pour le moment ) mais ça m'intéresse. )

Hiura, sans rentrer dans les détails, la promesse des concepts c'était de simplifier l'utilisation des templates, d'éradiquer les messages d'erreurs de trois kilomètres et de balayer la montagne de hack horripilant (classe de traits, metaprogrammation...) qui règne à l'heure actuelle sur la programmation générique.

Au delà du message d'erreur, c'est quand même de dire clairement avant la compilation ce qui est requis.

Je ne jette la pierre ni a l'amateur, ni a l'idee sous-jacente aux concepts, mais a sa realisation.

Pourquoi ? Je veux dire : j'ai lu ( de travers ) les papiers donnés précédemment mais je n'ai rien trouvé de si compliqué, du moins rien qui ne soit inaccessible.
Ou bien tu parles de la réalisation interne ( pas côté utilisateur donc ) ?

[Jean-Marc.Bourguet]

Au delà du message d'erreur, c'est quand même de dire clairement avant la compilation ce qui est requis.

D'accord.

Pourquoi ? Je veux dire : j'ai lu ( de travers ) les papiers donnés précédemment mais je n'ai rien trouvé de si compliqué, du moins rien qui ne soit inaccessible.
Ou bien tu parles de la réalisation interne ( pas côté utilisateur donc ) ?

Disons coté gourou à qui on vient poser les questions quand "ça ne marche pas" et qui essaye d'expliquer non seulement les règles mais leur pourquoi.

Le texte normatif ressemble un peu trop parfois à une description fonctionnelle et pas assez à une spécification (on décrit comment plutôt que quoi).