Discussion :

[Klaim]

C'est marrant que tu le cites pas mais

les templates de variable (N3651) qui permettent par exemple de définir pi = 3.1415926535897932385 universellement pour tous les types ;

Pour moi ce point la va enormement simplifier le code template.

[Flob90]

J'y ai pensé, mais j'ai encore un peu de mal à voir toute l'implication qu'il aura sur le code. Donc dans le doute j'ai préférer ne pas le commenter.

Pour moi c'est quand même le premier point qui est le plus important. Le caractère polymorphique des lambda était quand même quelque chose qui me faisait préférer les lambdas de boost::phoenix (et la syntaxe aussi).

[iksess]

Personnellement, je suis bien peu intéressé par les évolutions de la STL. Celle des compilateurs, un peu plus, mais entre Qt et Boost, pourquoi utiliser encore la STL qui a tant de retard...

[Gugelhupf]

@koala1

Heu... d'accord, on prend quel SGBDR comme référence

Tu n'imagines pas les différences qui peuvent exister au niveau du langage ne serait-ce qu'entre oracle, MsSql et MySql (pour ne citer que ceux là)

Je ne parle pas de la syntaxe des requête "simples" comme un select sur une seule table (voir meme sur plusieurs), mais de la syntaxe de certaines requêtes avancée

On ne prend aucun SGBDR comme référence, mais le standard SQL.
Oui je connais assez bien les SGBDR et leurs différences, aujourd'hui la plupart des SGBDR les plus connues et les plus réputés respectent la syntaxe de la norme SQL (même s'il y a des dérives).
SQL Server utilise le "+" pour concaténer les chaines de caractères tandis qu'avec Oracle ou PostgreSQL tu peux utiliser "||" comme indiqué dans la norme. Pour effectuer une limite la norme ne précise rien, SQL Server utilise TOP, tandis qu'Oracle utilise ROWNUM (vraiment pas terrible), LIMIT employé par PostgreSQL et MySQL (préférence pour celui de PostgreSQL car plus instinctif).
Et bien d'autres petits ajouts que les SGBDR se permettent pour simplifier la vie du développeur comme le IF ternaire ou les fonctions de conversion chaine/date (to_date/to_char pour Oracle et PostgreSQL, ou le nullissime convert de SQL Server...), ou encore l'utilisation d'opérateur de différence "!=" au lieu de "<>"...

Enfin bref, tout ça pour dire que le SQL c'est un truc qu'on ne peut pas réinventer, donc LINQ ou les fonctions chainées...
Pour finir cette syntaxe SQL, pourrait même être utilisée comme sucre syntaxique dans le code, mais je préfèrerais tout de même qu'il y ait une vérification de la chaine SQL, donc respect de la norme SQL.

[Klaim]

Personnellement, je suis bien peu intéressé par les évolutions de la STL. Celle des compilateurs, un peu plus, mais entre Qt et Boost, pourquoi utiliser encore la STL qui a tant de retard...

Parceque c'est la seule bibliotheque qui est garantiee d'etre toujours dispo, toujours implementee par tous les compilateur C++ qui declarent etre suivre le standard.

Peu importe le language, aucune autre bibliotheque que la bibliotheque standard du language ne peut donner des garanties de portabilite et de stabilite d'interface aussi forte.

Quand quelque chose devient officillement standard (et non de-facto standard), tu sais que ca va pas bouger pendant tres longtemps et que t'y auras acces quel que soit ton compilateur; contrairement a quand quelque chose est un standard "de-facto", ce qui veut dire que c'est beaucoup utiliser.

Boost.Filesystem est pas encore standard et a subit pas mal de gros changements de l'interface et du comportement. Et je parle meme pas de Boost.Thread. Les deux sont devenu standard mais leur interface diferrent dans les details de la version boost.
Boost reste un bon indice de ce qui pourrait devenir standard. Mais ca reste different d'un standard. C'est plus ou moins un label de qualite.

[JolyLoic]

Le draft de la prochaine norme C++14 est disponible !
sous le doux nom de N3690

Juste pour préciser pour ceux qui ne suivent pas de très près le processus, le draft est le document de travail courant qui est remis à jour après chaque réunion. Ce qui fait de cette version une version un peu particulière c'est que ce draft part en relecture finale pour la version C++14 de la norme. Il ne devrait plus y avoir de nouveautés ajoutées, seulement des corrections apportées, à la demande d'un pays membre de l'ISO. Ce qui signifie entre autres que les fabricants de compilateurs ont désormais une vision assez claire de ce qu'ils doivent faire, et peuvent commencer à implémenter le C++14 sans trop de craintes.

Il a été approuvé lors du meeting de Bristol durant laquelle les membres du comité ont voté un à un les ajouts faits à ce CD (Committee Draft).

Par rapport au C++ 11, il y a eu d'autres ajouts que ceux faits à Bristol, dans des réunions précédentes, mais ce qui n'a pas été ajouté là devra attendre le prochain train (C++17, selon les plans)

En parallèle se poursuivent les Technical Specifications (TS - filesystem, networking, concurrency, etc.) et les proposals pour C++1y qui sera cette fois une nouvelle version majeure du langage comme C++11 l'a été pour C++98.

Les TS sont une nouveauté par rapport à la dernière version du langage. L'objectif est d'accélérer à la fois le rythme de sortie de la norme, et la quantité de changements qu'il y aura dedans. On doit trouver un équilibre entre plusieurs points de vus contradictoires mais valables :
- Quelque-chose dans la norme est très difficile à retirer par la suite, donc ce qui va dans la norme doit être solide et éprouvé
- Beaucoup d'implémentations sont frileuse à travailler sur des fonctions qui n'ont pas été normalisées, de peur de devoir refaire leur travail si elles évoluent, ou de le jeter si elles ne passent pas.
- Comme on tente désormais d'être date-driven pour les sorties de version de la norme, il serait dommage de voir une fonctionnalité importante manquer à 1 mois prêt. Et il serait dommage pour la même raison de voir quelquechose de pas fini accepté de manière prématurée.

Ces TS ont donc pour objectif de fournir des documents officiels, sortant à la date qu'ils veulent, sans corrélation avec les dates du standard, assez solide pour encourager les gens à les implémenter, mais assez souple pour pouvoir être encore modifiés avant l'introduction définitive dans une norme.

L'avenir nous dira ce que ce numéro d'équilibriste donne.

[JolyLoic]

Par contre je trouve qu'il manque des fonctionnalité plus "haut niveau" dans le C++ STL comme un std::plugin (manipuler/charger des plugins)

C'est un sujet très difficile à définir, et qui touche à des aspects que la norme ignore sciemment aujourd'hui (compatibilité binaire...). Le seul papier que j'ai vu sur le sujet était déjà ancien, assez vague, et supposait les modules acceptés dans la langage.

ou une fonction permettant d'avoir la liste des serveurs DNS utilisés par l'ordinateur

Le groupe de travail sur le réseau a probablement des projets de ce type en vue.

, accéder à des bases de données en renseignant le pilote à utiliser, etc.

C'est là aussi un sujet complexe et difficile. A Bristol a été décidée la création d'un groupe de travail sur le sujet. Mais mon opinion est qu'aujourd'hui, il manque encore de monde pour travailler sur le sujet, que ce soit en taille pure du groupe de travail, ou par sa composition qui ne regroupe pas assez d'acteurs importants du marché à mon goût.

Très intéressant, mais j'espère qu'ils vont inclure quelque chose dans cette norme (Ou au pire dans le C++17): le static_if

Il n'y aura pas de static_if pour 2014, et j'espère fortement qu'il n'y en aura pas pour 2017. Ou du moins que s'il y en a, qu'il sera assez bridé pour en rendre sont utilisation moins dangereuse.

<troll>
Vu qu'ils ont mis 8 ans pour sortir la précédente révision on peut estimer que C++14 s’appellera C++19, voir C++2x
</troll>

La situation est assez différente, C++11 était gouverné par les fonctionnalités, avec l'idée d'une norme par décennie au mieux, avec donc la volonté de ne pas s’arrêter avant d'avoir mis dedans "ce qu'il fallait". Désormais, on travaille plus en mode dirigé par le planning, avec des dates de sortie fixées à l'avance.

De plus, en terme d'étapes, pour C++11, il n'y a eu aucun retard à partir du moment où le draft a été publié pour validation par les pays (c'est avant d'arriver à ce draft que les retards se sont accumulés). Or, on vient d'atteindre précisément cette étape pour le C++14, donc je dirais que pour l'instant, tout est sur les rails.

Pour ma part j'attends plutôt des concepts qui simplifient le développement, ou rend le code source multiplateforme comme :
[LIST][*]les modules ! (l'équivalent des package/import en Java ou namespace/using en C#).

Moi aussi je les attends. Et beaucoup de monde les attendent. Doug Gregor en a implémenté une version préliminaire pour Clang, et avait l'air de dire que cette version était dans un état assez avancé pour qu'une nouvelle proposition puisse voir le jour prochainement. J'ai entendu d'autres membres du commité dire que s'il y avait une fonctionnalité et une seule qui justifierait de décaler C++17, c'est bien celle là. Et je suis d'accord ![/QUOTE]

[dynarray]
Ça peut être sympa à utiliser comme conteneur.

Je n'utiliserait pas ce mot pour les qualifier... Que ce soit dans leur version langage, avec les array of variable lenght, ou dans la version bibliothèque avec les dynarray, je pense que je n'utiliserai pas ces conteneurs par défaut, mais uniquement dans une phase d'optimisation du code (et toujours avec la version dynarray, pas la version langage).

[germinolegrand]

Je remercie de tout cœur JolyLoic pour les précisions apportées !

Je donnerai mon avis personnel dans un prochain post .

[Klaim]

Moi aussi je les attends. Et beaucoup de monde les attendent. Doug Gregor en a implémenté une version préliminaire pour Clang, et avait l'air de dire que cette version était dans un état assez avancé pour qu'une nouvelle proposition puisse voir le jour prochainement. J'ai entendu d'autres membres du commité dire que s'il y avait une fonctionnalité et une seule qui justifierait de décaler C++17, c'est bien celle là. Et je suis d'accord !

Ah ben ca rassure un peu ca

[germinolegrand]

Voici donc mon avis personnel sur ces ajouts :

lambdas génériques

Oui ! Je dis oui ! Enfin !

capture généralisée par move

Ça ça va grandement simplifier l'utilisation des lambdas. On va pouvoir faire voyager des unique_ptr par exemple .

les std::dynarray et Runtime-Sized Arrays

Oui, parfois ça manque.

les templates de variable

Un joli sucre syntaxique, qui néanmoins ne fait de tord à personne .

des réductions des utilitaires de traits

Ça c'est cool, leur utilisation basique est extrêmement verbeuse. Il manquerait juste une série de variadic_traits pour compléter (leur absence rend difficile l'utilisation des variadics templates).

des contraintes moindres pour les fonctions constexpr

Je les aimes pas beaucoup mais bon, c'est peut-être parce qu'on ne peut pas faire autre chose que de la récursivité actuellement (je ne suis pas très adroit avec), ça va peut-être arranger les choses .

std::exchange

Là oui, ça peut être pratique, pour les unique_ptr notamment.

std::quoted

Tout ce qui peut améliorer les iostream est bon à prendre. Et quoted est un bon début .

les std::shared_mutex

J'utilise déjà pas de mutex, je n'utiliserai probablement pas plus celle-ci ^^.

std::optional

Bon à prendre. Les tuples/pair qui prennent cette place ne sont pas aisés à manipuler (ni fantastiques question sémantique).

des user-defined literals dans la STL

Là ils en ont fait une belle... je n'ai pas compris pourquoi ils n'ont pas inliné le namespace std uniquement pour ça. Cela rend donc inutilisables ces petits rien pourtant forts utiles en dehors d'une using namespace std;. Comment pourra-t-on dire d'avoir la main légère sur les using namespace (je les évite autant que possible pour ma part !) si la norme impose le contraire ? D'autant plus que cela crée un énorme déséquilibre entre le code dans les headers et celui des .cpp puisque si les using namespaces sont à éviter (selon moi) dans les .cpp actuellement, ils sont carrément à proscrire dans les headers (pour les raisons que l'on sait tous). Et maintenant que l'on peut initialiser ses attributs dans la déclaration de la classe, il ne me semble pas incongru de pouvoir trouver m_str = "default string"s; ou m_time = 22h;. Donc soit je n'ai pas compris le code contenu dans le proposal, soit les proposals sont acceptés en dépit du bon sens sans corrélation avec les autres éléments ajoutés en même temps... bref, que l'on m'explique.

std::make_unique

Ça c'est bien dommage que ça soit nécessaire pour bug-fix.
Les malloc les débutants connaissent plus, bientôt même le new ils connaîtront plus . Bon l'uniformisation c'est sympa... mais, le nombre de auto va encore exploser. Mais j'y reviens.

la déduction de type retour

Ça, je sens que ça va faire mal. Vous imaginez mettre auto dans l'interface d'une bibliothèque ? Les utilisateurs vous tomberont dessus à bras raccourcis, et vous mangeront tout crû, avec de la sauce à la menthe. Beurk, pauvres lions.

La fonctionnalité est bien, et pour rien au monde je ne voudrais qu'elle soit retirée (bon ok, mais faudra allonger le million). Je crains qu'à l'instar des shared_ptr on en mette partout "parce que y'a pas besoin de réfléchir" (sic !). Il faudra de solides guidelines pour encadrer ça.

Si je crains pour auto c'est pour une bonne raison (pas parce que je ne sais pas ce qui est derrière, ce qui fut le cas jadis ). La raison est que les parseurs des IDE, aussi ingénieux soit-ils, ne sont pas des compilateurs. Or ce qui se passe actuellement, c'est qu'au moindre auto, au moindre decltype, la code-completion disparait. Et c'est dramatique. Dramatique, parce que si vous gagnez en temps et en lisibilité en faisant disparaître les monstrueux itérateurs, vous voilà revenu à l'âge de pierre : il vous faut connaître toutes les méthodes par cœur, de leur nom sans la moindre faute d'orthographe à leurs arguments.

Le auto j'en mets partout, autant que je peux. Parce que c'est bon tant de généricité gratuite pour si peu cher. Aussi j'espère fortement que les parseurs d'IDE vont trouver le moyen de contourner auto.

Toutefois je suis globalement content de ce qui se prépare .

[Klaim]

Un joli sucre syntaxique, qui néanmoins ne fait de tord à personne .

A ce que je sache ce n'est pas juste du sucre syntactique puisqu'on ne pouvait pas faire ce que la feature propose auparavant.

Je les aimes pas beaucoup mais bon, c'est peut-être parce qu'on ne peut pas faire autre chose que de la récursivité actuellement (je ne suis pas très adroit avec), ça va peut-être arranger les choses .

Il y aurait des indices comme quoi il y a des cas ou la limitation de la recursivite combine a l'utilisation de constexpr pour une fonction utilisee avec des paramettres runtime faisait des problemes de performance. Du coup, meme au dela de l'aspect pratique, visiblement ca regle des probleme de performance variables selon les utilisations aussi.

Là oui, ça peut être pratique, pour les unique_ptr notamment.

C'est clair! J'ai tout un tas de cas ou j'ai du organiser mon code differement de la maniere la plus evidente parceque cette feature manquait.

Là ils en ont fait une belle... je n'ai pas compris pourquoi ils n'ont pas inliné le namespace std uniquement pour ça. Cela rend donc inutilisables ces petits rien pourtant forts utiles en dehors d'une using namespace std;. Comment pourra-t-on dire d'avoir la main légère sur les using namespace (je les évite autant que possible pour ma part !) si la norme impose le contraire ? D'autant plus que cela crée un énorme déséquilibre entre le code dans les headers et celui des .cpp puisque si les using namespaces sont à éviter (selon moi) dans les .cpp actuellement, ils sont carrément à proscrire dans les headers (pour les raisons que l'on sait tous). Et maintenant que l'on peut initialiser ses attributs dans la déclaration de la classe, il ne me semble pas incongru de pouvoir trouver m_str = "default string"s; ou m_time = 22h;. Donc soit je n'ai pas compris le code contenu dans le proposal, soit les proposals sont acceptés en dépit du bon sens sans corrélation avec les autres éléments ajoutés en même temps... bref, que l'on m'explique.

Si j'ai bien compris les operateurs sont definis dans des namespaces sous std mais ils sont bien inline dans std. Ou j'ai rien compris non plus?

Ça c'est bien dommage que ça soit nécessaire pour bug-fix.
Les malloc les débutants connaissent plus, bientôt même le new ils connaîtront plus . Bon l'uniformisation c'est sympa... mais, le nombre de auto va encore exploser. Mais j'y reviens.

J'ai pas compris de quel bugfixe tu parles?

Ça, je sens que ça va faire mal. Vous imaginez mettre auto dans l'interface d'une bibliothèque ? Les utilisateurs vous tomberont dessus à bras raccourcis, et vous mangeront tout crû, avec de la sauce à la menthe. Beurk, pauvres lions.

A ce que je sache, auto ne peut pas etre utilise en type de retour si il n'y a pas l'implementation de la fonction visible au compilateur (comme actuellement quand tu as aussi decltype).
Donc je vois pas bien le probleme... sauf si la fonction est longue et dans le header et n'est pas template evidemment, ou ca rendrais le code emoins lisible.
Ca fais partie des features qui seront certainement abusees un temps, mais je pense qu'on a pas de moyen d'en rechaper si on veut pouvoir aussi ecrire du code generique simple.

La fonctionnalité est bien, et pour rien au monde je ne voudrais qu'elle soit retirée (bon ok, mais faudra allonger le million). Je crains qu'à l'instar des shared_ptr on en mette partout "parce que y'a pas besoin de réfléchir" (sic !). Il faudra de solides guidelines pour encadrer ça.

C'est clair.

Si je crains pour auto c'est pour une bonne raison (pas parce que je ne sais pas ce qui est derrière, ce qui fut le cas jadis ). La raison est que les parseurs des IDE, aussi ingénieux soit-ils, ne sont pas des compilateurs. Or ce qui se passe actuellement, c'est qu'au moindre auto, au moindre decltype, la code-completion disparait. Et c'est dramatique. Dramatique, parce que si vous gagnez en temps et en lisibilité en faisant disparaître les monstrueux itérateurs, vous voilà revenu à l'âge de pierre : il vous faut connaître toutes les méthodes par cœur, de leur nom sans la moindre faute d'orthographe à leurs arguments.

Alors je ne sais pas ce que tu utilises comme IDE mais je n'ai pas eu ce probleme avec auto, je ne l'ai eu qu'avec des lambda. Je pense pas que ca s'ameliorera avec les lambda generiques (qui ajoutent auto donc ) mais je ne pense pas que ca sera de vrai problemes pour les implementateur de IDE, parceque depuis qu'il y a LLVM dispo et gratos, ils n'ont plus aucune excuse.

Le auto j'en mets partout, autant que je peux. Parce que c'est bon tant de généricité gratuite pour si peu cher. Aussi j'espère fortement que les parseurs d'IDE vont trouver le moyen de contourner auto.

Toutefois je suis globalement content de ce qui se prépare .

Pareil

[Arzar]

Moi aussi je les attends. Et beaucoup de monde les attendent. Doug Gregor en a implémenté une version préliminaire pour Clang, et avait l'air de dire que cette version était dans un état assez avancé pour qu'une nouvelle proposition puisse voir le jour prochainement. J'ai entendu d'autres membres du commité dire que s'il y avait une fonctionnalité et une seule qui justifierait de décaler C++17, c'est bien celle là. Et je suis d'accord !

Et qu'en est-il des concept-lite proposés par Stroustrup, Sutton et Dos Reis et implémentés dans une branche de GCC 4.9 ?
J'avais l'impression que cette forme intermédiaire simplifiée était ce qui était maintenant mis en avant par le comité, ce qui permettrait d'avoir un TR pour les concepts dès 2014. Mais en fait il y a donc encore plusieurs design des concept qui se font concurrence ?

D'ailleurs à propos des concept-lite je suis tombé sur les slides d'une présentation à la conf c++ now qui explique les concept-lite beaucoup plus simplement que dans le proposal. Et ma fois la syntaxe est plutôt chouette. On est finalement pas si loin des concepts comme initialement envisagée, la seule grosse différence étant l'absence de concept_map j'ai l'impression.

(Petite parenthèse je note que la feature des variables template semble nécessaire pour implémenter les concept-lite, ça expliquerait peut être pourquoi ce papier qui semble tomber du ciel - aucune apparition dans les précédents mailing, a été accepté du premier coup à Bristol ?).

Sinon je suis assez estomaqué par la généralisation des constexpr, je ne pensais pas que le comité irait aussi loin.
Il est bien connu que constpexr en C++11 a été sévèrement bridé, pour éviter de prendre des risques, et qu'il était prévu dès le début de l'étendre dans les standards post c++11, mais quand même si je comprends bien on passe de un seul et unique statement return en C++11 autorisé par fonction constepxr à euuu.... quasiment tout le c++ d'autorisé ?
Excepté deux trois trucs comme l’interdiction de goto/try-catch/variable statique/variable non initialisé + quelques restrictions naturelles comme pas d'allocation dynamique possible + les seules types utilisables sont les built-in et les types dont le constructeur est constepxr, on pourra donc tout faire dans une fonction constepxr ? Comment vont se débrouiller les compilateurs ? Il va falloir qu"ils précompilent les fonctions constexpr pour pouvoir les exécuter pendant la vrai compilation, qqchose comme ça ?

[Flob90]

J'ai un peu de mal à voir où le std::exchange a pu vous manquez à ce point pour std::unique_ptr. Il n'y a pas std::exchange, mais il y a quand même std::swap. Je suis d'accord c'est à peine plus verbeux (1 ligne) mais on est loin de la feature indispensable je trouve.

[JolyLoic]

Et qu'en est-il des concept-lite proposés par Stroustrup, Sutton et Dos Reis et implémentés dans une branche de GCC 4.9 ?
J'avais l'impression que cette forme intermédiaire simplifiée était ce qui était maintenant mis en avant par le comité, ce qui permettrait d'avoir un TR pour les concepts dès 2014. Mais en fait il y a donc encore plusieurs design des concept qui se font concurrence ?

Il n'y a pas vraiment plusieurs design concurrents, il y a un design partiel qui a été proposé, Concept-Lite, et je pense que la question la plus importante qui a été posée est "sera-t-il possible d'aller de ce design partiel à un design plus complet", la question annexe étant "comment gérer les concepts avec une syntaxe légère, en particulier pour les lambdas".

D'ailleurs à propos des concept-lite je suis tombé sur les slides d'une présentation à la conf c++ now qui explique les concept-lite beaucoup plus simplement que dans le proposal. Et ma fois la syntaxe est plutôt chouette. On est finalement pas si loin des concepts comme initialement envisagée, la seule grosse différence étant l'absence de concept_map j'ai l'impression.

Pas exactement. Les concepts map sont effectivement absentes, et telles que je vois les choses, elles ne sont pas prêtes de revenir. Non, la plus importante différence est dans l'absence de validation de l'implémentation. Les concepts initiaux vérifiaient deux choses : Que l'utilisateur d'un template essayait de l'instancier avec des types conformes, et que l’implémentation d'un template n'utilisait que ce qu'il avait promis d'utiliser des types passés en argument. Cette seconde partie est absente des concepts lite.

Il y a eu une longue discussion en début de réunion à Bristol pour savoir si on mettait les concept light dans C++14. Finalement il a été décidé de créer un TS dédié à ce sujet ainsi qu'à une syntaxe allégée pour les templates. L'objectif est que le TS soit prêt à peut près en même temps que le C++14 (il y a moins de lourdeurs administratives pour la validation d'un TS, donc ça laisse un peu plus de temps), dans l'espoir que des compilateurs commencent à l'implémenter au plus vite, avant même que le TS ne soit transféré dans un working paper, et surtout avant C++17.

Sinon je suis assez estomaqué par la généralisation des constexpr, je ne pensais pas que le comité irait aussi loin.
Il est bien connu que constpexr en C++11 a été sévèrement bridé, pour éviter de prendre des risques, et qu'il était prévu dès le début de l'étendre dans les standards post c++11, mais quand même si je comprends bien on passe de un seul et unique statement return en C++11 autorisé par fonction constepxr à euuu.... quasiment tout le c++ d'autorisé ?
Excepté deux trois trucs comme l’interdiction de goto/try-catch/variable statique/variable non initialisé + quelques restrictions naturelles comme pas d'allocation dynamique possible + les seules types utilisables sont les built-in et les types dont le constructeur est constepxr, on pourra donc tout faire dans une fonction constepxr ? Comment vont se débrouiller les compilateurs ? Il va falloir qu"ils précompilent les fonctions constexpr pour pouvoir les exécuter pendant la vrai compilation, qqchose comme ça ?

Comment ils vont faire, je ne sais pas trop, je n'ai pas assisté à cette partie de la discussion, mais j'imagine qu'il ne devait pas y avoir une telle marge en terme d'implémentation entre ce qu'ils doivent déjà faire maintenant (et qui a été déclaré comme la fonctionnalité du C++11 la plus longue à mettre en place par certains fabricants de compilateur) et ce qu'il est possible de faire désormais.

Sur le pourquoi des choses, les limitations actuelles posaient des vrais problèmes. En gros, une fonction constexpr peut aussi servir au runtime. Or, les limitations d'écriture des fonctions constexpr faisaient que pour en écrire une valide, il fallait qu'elle soit écrite de manière totalement non optimale pour le runtime. Ce qui forcerait à écrire deux fois les même fonctions, une fois pour le compile time, une fois pour le runtime, et à choisir la bone version au bon moment, ce qui n'est pas aisé et bloque toute généricité. Maintenant, on peut écrire une fonction naturellement et efficacement qui pourra servir au compile time et au runtime.

Howard Hinnant a déjà déclaré qu'avec cette nouvelle fonction il avait pu définir une fonction (jour, mois, année) => date qui tournait 3 fois plus vite quand une partie des arguments était connue à la compilation, sans que l'implémentation soit trop complexe ou artificielle.

[koala01]

Là ils en ont fait une belle... je n'ai pas compris pourquoi ils n'ont pas inliné le namespace std uniquement pour ça. Cela rend donc inutilisables ces petits rien pourtant forts utiles en dehors d'une using namespace std;. Comment pourra-t-on dire d'avoir la main légère sur les using namespace (je les évite autant que possible pour ma part !) si la norme impose le contraire ? D'autant plus que cela crée un énorme déséquilibre entre le code dans les headers et celui des .cpp puisque si les using namespaces sont à éviter (selon moi) dans les .cpp actuellement, ils sont carrément à proscrire dans les headers (pour les raisons que l'on sait tous). Et maintenant que l'on peut initialiser ses attributs dans la déclaration de la classe, il ne me semble pas incongru de pouvoir trouver m_str = "default string"s; ou m_time = 22h;. Donc soit je n'ai pas compris le code contenu dans le proposal, soit les proposals sont acceptés en dépit du bon sens sans corrélation avec les autres éléments ajoutés en même temps... bref, que l'on m'explique.

L'avantage de partir d'un espace de noms imbriqué est de donner l'accès à une fonctionnalité (ou plutot à un ensemble de fonctionnalités ) sans impact sur les fonctionnalités existantes de l'espace de noms "parent".

Et tu sais comme moi que l'espace de noms std fourni... énormément de fonctionnalités

L'idée sous-jacente à l'espace de noms imbriqué étant que l'on peut le modifier / l'améliorer "facilement" et que les gens qui l'utiliseront sauront faire "la part des choses" entre le bénéfice apporté par la fonctionnalité et... le risque inérant au fait que l'on n'a peut pas encore forcément mesuré l'ampleur de la tache.

C'est aussi un moyen relativement simple de pouvoir rajouter des fonctionnalités sans nécessiter l'ensemble des validations requises pour la modification de la norme

C'est, par exemple, ce qui s'est passé pour l'espace de noms tr1

Il y a fort à parier que l'espace de noms sera inliné dans std "assez rapidement" (pour la norme ca peut en tout cas être considéré comme rapide )...

Ils sont sans doute "simplement" estimé que c'était le meilleur moyen de faire passer cela dans la norme avant que cela ne devienne réellement la norme

[germinolegrand]

L'avantage de partir d'un espace de noms imbriqué est de donner l'accès à une fonctionnalité (ou plutot à un ensemble de fonctionnalités ) sans impact sur les fonctionnalités existantes de l'espace de noms "parent".

Et tu sais comme moi que l'espace de noms std fourni... énormément de fonctionnalités

L'idée sous-jacente à l'espace de noms imbriqué étant que l'on peut le modifier / l'améliorer "facilement" et que les gens qui l'utiliseront sauront faire "la part des choses" entre le bénéfice apporté par la fonctionnalité et... le risque inérant au fait que l'on n'a peut pas encore forcément mesuré l'ampleur de la tache.

C'est aussi un moyen relativement simple de pouvoir rajouter des fonctionnalités sans nécessiter l'ensemble des validations requises pour la modification de la norme

C'est, par exemple, ce qui s'est passé pour l'espace de noms tr1

Il y a fort à parier que l'espace de noms sera inliné dans std "assez rapidement" (pour la norme ca peut en tout cas être considéré comme rapide )...

Ils sont sans doute "simplement" estimé que c'était le meilleur moyen de faire passer cela dans la norme avant que cela ne devienne réellement la norme

Ils sont inline dans le std. Moi ce que je ne comprend pas c'est pourquoi std n'est pas inliné (uniquement pour ces literals), puisqu'ils ne risquent en aucun cas de conflit, ces literals sont réservés par la norme. Or ces literals sont inutilisables s'ils ne sont pas dans l'espace global (ou disons inlinés pour l'être).

Alors je ne sais pas ce que tu utilises comme IDE mais je n'ai pas eu ce probleme avec auto, je ne l'ai eu qu'avec des lambda. Je pense pas que ca s'ameliorera avec les lambda generiques (qui ajoutent auto donc ) mais je ne pense pas que ca sera de vrai problemes pour les implementateur de IDE, parceque depuis qu'il y a LLVM dispo et gratos, ils n'ont plus aucune excuse.

Je l'espère de tout coeur. J'utilise C::B (pour son multiplateforme).

[gbdivers]

Pour ceux qui veulent tester la déduction des types de retour des fonctions "normales" avec auto (N3638), cette fonctionnalité est disponible dans gcc 4.9

Code :

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

auto f() { return 42; } // return type is int

Egalement disponible, l'initialisation des variables lors de la capture :

Code :

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

[x = 42]{ ... };

Et les tableaux de tailles variables mais fixe

Code :

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

1
2
3
4
5
void f(int n) {
  int a[n] = { 1, 2, 3 }; // throws std::bad_array_length if n < 3
  [&a]{ for (int i : a) { cout << i << endl; } }();
  &a; // error, taking address of VLA
}

Sur Ubuntu (et d'autres distribution linux), il suffit d'installer le paquet gcc-snapshot pour avoir gcc 4.9

Pour suivre les ajouts du C++14 dans gcc4.9 : C++1y/C++14 Support in GCC

(les codes d'exemple donnés proviennent de la documentation de gcc)

[JolyLoic]

Pour ceux qui veulent tester la déduction des types de retour des fonctions "normales" avec auto (N3638), cette fonctionnalité est disponible dans gcc 4.9

Code :

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

1
2
3
int& f();
auto  i1 = f(); // int
decltype(auto) i2 = f(); // int&

Je ne vois pas trop ce que tu veux dire là. Il s'agit d'auto tel qu'on le connait déjà... (sauf la troisième ligne qui me semble étrange, mais j'ai peu l'habitude de decltype).

La nouveauté est plutôt de pouvoir écrire :

Code :

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

1
2
3
4
auto f(int i, int j)
{
    return i+j;
}

Ce qui n'est pas si avantageux sauf quand les types sont compliques :

Code :

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

1
2
3
4
auto MyCont::begin()
{
    return myData.begin();
}

Ou encore plus quand il est difficile de le connaître à la compilation statiquement :

Code :

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

1
2
3
4
5
template<class T, class U>
auto f(T t, U u)
{
    return u+v;
}

[gbdivers]

Tu as mal lu , Loïc

(j'ai édité mon code pendant que tu tapais ton message )

[Klaim]

Et les tableaux de tailles variables mais fixe

Ya aussi std::dynarray?