Discussion :

[Alp]

Tiens

Il y a quelques jours encore, j'avais lu que la publication étaient prévue fin 2009.

[HanLee]

Pfff, quand même je trouve ça mou.
Ils peuvent pas lever des fonds pour que ça aille plus vite franchement, avec tous les réseaux et partenariats d'entreprise qu'ils ont ?

----

Deuxièmement, je vais peut-être m'avancer un peu trop.
Je remarque que souvent, ils apportent beaucoup de correction au niveau syntaxique, au niveau des règles, ce qui est illégal ou légal d'écrire.

La manière dont ils font ça me fait penser que c'est expérimental, empirique et pas très rigoureux.

Pourtant, le C++ dispose d'une grammaire, donc on peut appliquer les théorèmes et propriétés en théorie des langages, au moins partiellement !

Donc on peut raisonnablement penser qu'en spécifiant bien les prédicats, il soit possible d'en déduire une règle qui marche une bonne fois pour toute, à l'erreur de démonstration près !

En même temps, vous me direz, la grammaire du C++ est tellement horrible que...

[Alp]

D'un autre côté, regarde la complexité de la chose !

Il faut garder dans une certaine mesure une syntaxe de type C, on ne peut pas aller trop loin sinon ça deviendra un tout autre langage.

Après, faut qu'on reste compatible C++98 et même normes précédentes.

Le tout en essayant de fournir des outils pratiques et efficaces aux programmeurs C++.

Bref si il y a un comité qui bosse sur ça et des milliers de gens qui apportent leur pierre à l'édifice c'est que ça ne doit pas être si simple que ça

Et puis ne parlons pas du fait que les compilos doivent pouvoir suivre assez vite Je me demande bien comment ça va se passer pour C++0x là...

[HanLee]

D'un autre côté, regarde la complexité de la chose !

Il faut garder dans une certaine mesure une syntaxe de type C, on ne peut pas aller trop loin sinon ça deviendra un tout autre langage.

Justement, c'est complexe, c'est pourquoi je disais que pour ça, raisonner formellement et directement sur la syntaxe/grammaire permettrait potentiellement d'aller plus vite, de faire moins d'erreurs.

Assisté par ordinateur bien évidemment.

Après, faut qu'on reste compatible C++98 et même normes précédentes.

Le tout en essayant de fournir des outils pratiques et efficaces aux programmeurs C++.

Bref si il y a un comité qui bosse sur ça et des milliers de gens qui apportent leur pierre à l'édifice c'est que ça ne doit pas être si simple que ça

Il y a des milliers de gens qui apportent leur pierre, mais la grande majorité le font pendant leur temps libre, ou de manière bénévole.
C'est juste au niveau gestion de projet que je critiquerais.

[Alp]

Ok. Bon c'est clair qu'on peut redire sur la gestion du "projet C++". Mais les choses se concrétisent progressivement. De toute manière, d'ici peu, les compilos sauront exactement ce qu'ils ont à faire. Retarder de quelques mois la publication officielle ne changera pas grand chose pour eux.

[loufoque]

Pourtant, le C++ dispose d'une grammaire, donc on peut appliquer les théorèmes et propriétés en théorie des langages, au moins partiellement !

C++ tient à ne pas se rapprocher des théories des langages, logique et sémantique et à rester un langage de programmation pragmatique.
Ayant moi-même fait de l'info théorique en quantité non négligeable (j'ai fait une année à l'ENS) je trouve qu'ils ont raison.

[JolyLoic]

C"'est une conclusion de la dernière réunion. Les processus ISO a des délais importants, qui s'ajoutent aux délais nécessaires pour faire un bon standard.

D'où l'idée de publier un "brouillon officiel" pour revue aux différents membres plus tôt (revue finie en 2009), brouillon qui aura encore surement plein d'erreurs de détail, mais sera globalement fini, et sur lesquels les implémenteurs pourront se baser avec sérénité, sans risque de voir leur travail réduit à néant lors d'une modification ultérieure.

Par contre, la version finalisée officielle sera effectivement prévue plus tard (200A ?).

[HanLee]

C++ tient à ne pas se rapprocher des théories des langages, logique et sémantique et à rester un langage de programmation pragmatique.
Ayant moi-même fait de l'info théorique en quantité non négligeable (j'ai fait une année à l'ENS) je trouve qu'ils ont raison.

Mais je ne lui reproche pas son côté pragmatique.

C'est juste que quand bien même sa grammaire est plutôt imparfaite niveau théorie des langages, il y a quand même des invariants à maintenir, au niveau de la norme du C++.

Des ambigüités qu'il faut lever ou non.

Et ça, même si sa grammaire est très pragmatique, peu uniforme, ça doit sûrement pouvoir être vérifié rigoureusement.

D'un côté, on se farcit aussi l'héritage de certaines parties du C assez peu jolies, ce qui explique certaines choses.

[Klaim]

C'est juste que quand bien même sa grammaire est plutôt imparfaite niveau théorie des langages, il y a quand même des invariants à maintenir, au niveau de la norme du C++.

Des ambigüités qu'il faut lever ou non.

Mis a part quelques ajouts, je ne vois que des réduction des ambiguitées justement.

Les concepts et concept_map pour clarifier tout ce qui est template (rendre les erreurs de compilo explicites et permettre de contourner les problèmes des "mots"), l'initialization unifiée pour rendre les initialization pareil partout (et du coup plus claires, même si les autres façons d'initializer sont toutjours là), les fonctions lambda pour ne plus avoir a écrire des class fonctors, etc...

Au final, c'est surtout dans la STL/SL qu'il y a des ajouts.

Mais globalement je me dit qu'il se peut qu'au début les débutants aient plus de mal parcequ'on tentera de leur apprendre plus de choses que nécessaire, parceque nous même ne seront pas encore habitué aux nouvelles facilitées du language.

[Alp]

Il faudrait déjà pour commencer qu'on commence à enseigner aux débutants actuels le vrai C++ actuel, avant de se pencher sur l'enseignement de C++0x...

[HanLee]

Sinon, la nouvelle syntaxe de déclarations de fonctions, c'est pas mal, mais j'la trouve très laide .

[loufoque]

C++ est défini par des mots et des phrases.
Pour pouvoir appliquer des théorèmes etc, il faudrait le décrire avec des règles d'inférence.

[JolyLoic]

As-tu lu n1885 et n1886 ?

[alex_pi]

Venant de la communauté "langage fonctionels", je vais juste faire un petit commentaire à ce niveau : Un certain nombre de langage "grand public" ont integré plusieurs de trait issus des langages fonctionnels. Je pense en particulier à python (et sans doute plein d'autres) ou il est très simple de faire une liste de fonction, une lambda abstraction, etc.
On a l'impression que pour C++0x, ils se sont dit qu'il fallait peut être faire pareil, ont commencé... et se sont arreté en cours de route ! Ok, on a maintenant une notation (assez horrible) pour faire une fermeture, où l'ont doit spécifier à la main quelles sont les variables que l'on copie et celle dont on garde juste la référence (obligatoire si l'on veut retourner la fonction, puisque la gestion de la mémoire se fait manuellement et que l'utilisation d'une variable dans la pile serait problématique.). Mais là, bam, on ne donne pas de type pour les fonctions, c'est compilo-dépendent (page 85 du draft de mai 2008) ! Alors on fait quoi de notre fermeture ? Si on n'en a pas le type, on ne peut pas la mettre dans un tableau, la retourner, la passer en argument... On perd tout intéret à avoir des fonctions annonymes. Je ne comprends vraiment pas pourquoi ils se sont embeter à ajouter ça au langage...

[Jean-Marc.Bourguet]

Alors on fait quoi de notre fermeture ?

(Il faudrait que je revoie ca, mais bon le temps me manque).

L'utiliser dans les contextes ou le type est deductible. Je suis d'accord ca limite l'utilite, mais il me semble que ca couvre les cas d'utilisations les plus courant tout en prevenant les cas incompatibles avec les modeles d'implementation courants.

[JolyLoic]

(Il faudrait que je revoie ca, mais bon le temps me manque).

Idem

Il me semble qu'on peut initialiser un std::function avec une telle expression, non ?

[Jean-Marc.Bourguet]

Idem

Il me semble qu'on peut initialiser un std::function avec une telle expression, non?

Ca devrait, c'est un contexte deductible il me semble.

(Ce qui me fait penser que ma premiere idee -- limiter la complexite d'implementation -- est fausse -- il faut vraiment que je relise cela pour voir comment la capture se fait et ce qui se passe apres le retour de la fonction; est-ce que c'est simplement des "upward closure" ou bien est-ce qu'on passe dans le domaine indefini ou bien on fait du GC sur les stack frames; je pensais a la premiere, je penche maintenant vers la seconde).

[Alp]

Idem

Il me semble qu'on peut initialiser un std::function avec une telle expression, non ?

J'avais lu le draft et je crois bien que c'est le cas oui.

[Emmanuel Deloget]

Venant de la communauté "langage fonctionels", je vais juste faire un petit commentaire à ce niveau : Un certain nombre de langage "grand public" ont integré plusieurs de trait issus des langages fonctionnels. Je pense en particulier à python (et sans doute plein d'autres) ou il est très simple de faire une liste de fonction, une lambda abstraction, etc.
On a l'impression que pour C++0x, ils se sont dit qu'il fallait peut être faire pareil, ont commencé... et se sont arreté en cours de route ! Ok, on a maintenant une notation (assez horrible) pour faire une fermeture, où l'ont doit spécifier à la main quelles sont les variables que l'on copie et celle dont on garde juste la référence (obligatoire si l'on veut retourner la fonction, puisque la gestion de la mémoire se fait manuellement et que l'utilisation d'une variable dans la pile serait problématique.). Mais là, bam, on ne donne pas de type pour les fonctions, c'est compilo-dépendent (page 85 du draft de mai 2008) ! Alors on fait quoi de notre fermeture ? Si on n'en a pas le type, on ne peut pas la mettre dans un tableau, la retourner, la passer en argument... On perd tout intéret à avoir des fonctions annonymes. Je ne comprends vraiment pas pourquoi ils se sont embeter à ajouter ça au langage...

Avec quand même le cas notable ou si la liste de capture n'est composée que de références, la fermeture est du type reference_closure<R(P)> (ou P est la liste des paramètres), une classe qui a un comportement défini (cf [func.referenceclosure], section 20.6.17 du dernier draft (pdf)).

En même temps, les closure ont été principalement ajoutées pour simplifier l'écriture de programmes utilisant les algorithmes de la CSL. Exit l'écriture de foncteurs pour résoudre des problèmes aussi simple qu'un test sur un des membres de la classe:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
namespace 
{
  struct is_male 
  { 
    bool operator()(const obj& o) 
    { return 'o.get_gender() == gender::male); } 
  };
}
void f()
{
  v.erase(std::remove_if(v.begin(), v.end(), is_male()), v.end());
}

Dorénavent, on pourra écrire le code de manière beaucoup plus compacte:

Code :

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

1
2
3
4
5
6
7
8
9
10
void f()
{
  // j'explose la ligne exprès pour bien différencier les différents arguments.
  v.erase(
    std::remove_if(
      v.begin(), 
      v.end(), 
      [](const pbj& o) { return (o.get_gender() == gender::male); }), 
    v.end());
}

Le code est largement lisible une fois qu'on a identifié qu'il s'agit d'une closure. On a pas besoin de définir une fonction ou un foncteur externe (donc un gain appréciable de temps), et le debuggage est simplifié puisqu'on a le code sous les yeux. L'utilisation des algorithmes de la CSL s'en trouve grandement simplifiée (à mon sens).

J'avoue que j'aurais aimé que le standard soit capable de typer l'objet fermeture qui est créé dans ce cas. On peut toujours utiliser les traits pour obtenir quelques informations, mais on est rapidement limité par les possibilités offertes par le système. La seule information qu'on a, c'est qu'un objet fermeture est callable - ça ne vas pas très loin... Exit donc l'écriture élégante de delegates simples (à défaut de pouvoir spécifier le type des delegates...).

Dans l'idée, même si on peut initialiser un std::function<T> avec un objet closure, il n'en reste pas moins que T est indéfini et inconnu, donc on ne peut définir d'objet de ce type (à moins de la stocker dans une variable définie comme étant du type "auto").

De plus, rien ne définit dans le standard que deux closure ayant la même liste de capture, les même paramètres et le même type de retour sont du même type.

En ce qui concerne la notation généralisée pour la définition de fonctions, j'avoue que j'ai un faible pour elle. Elle est très mathémique, dans le sens ou on définit une fonction auto F (S) -> S', ou S et S' sont respectivement le domaine d'entrée et le domaine de sortie de la fonction. Ca me plait plutôt bien. On est pas loin de la notation mathématique usuelle F : S -> S'. Bon, ok, je trouve la présence du mot-clefs auto et le wording du draft courant à ce sujet assez perplexants...

A noter que Herb Sutter a annoncé il y a déja un mois et demi que le premier draft "final" sera proposé en septembre. Il n'y a aucune chance d'avoir une ratification du standard en 2008, mais il n'est pas impossible que le standard sorte quand même en 2009 - comme prévu.

[alex_pi]

Dorénavent, on pourra écrire le code de manière beaucoup plus compacte:

Code :

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

1
2
3
4
5
6
7
8
9
10
void f()
{
  // j'explose la ligne exprès pour bien différencier les différents arguments.
  v.erase(
    std::remove_if(
      v.begin(), 
      v.end(), 
      [](const pbj& o) { return (o.get_gender() == gender::male); }), 
    v.end());
}

Justement, ce qui serait bien c'est que l'on puisse écrire des fonction à la "remove_if", attendant une fermeture en argument, pas juste les utiliser ! Mais peut être que l'on peu avec auto ? (malheureusement, on ne peut pas tester ;-))