C'est marrant que tu le cites pas mais
Pour moi ce point la va enormement simplifier le code template.Citation:
les templates de variable (N3651) qui permettent par exemple de définir pi = 3.1415926535897932385 universellement pour tous les types ;
Version imprimable
C'est marrant que tu le cites pas mais
Pour moi ce point la va enormement simplifier le code template.Citation:
les templates de variable (N3651) qui permettent par exemple de définir pi = 3.1415926535897932385 universellement pour tous les types ;
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).
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...
@koala1
On ne prend aucun SGBDR comme référence, mais le standard SQL.Citation:
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
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.
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.Citation:
Envoyé par iksess
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.
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.Citation:
Envoyé par germinolegrand
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)Citation:
Envoyé par germinolegrand
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 :Citation:
Envoyé par germinolegrand
- 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.
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.Citation:
Envoyé par Neckara
Le groupe de travail sur le réseau a probablement des projets de ce type en vue.Citation:
Envoyé par Neckara
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.Citation:
Envoyé par Neckara
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.Citation:
Envoyé par Lynix
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.Citation:
Envoyé par jmnicolas
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.
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]Citation:
Envoyé par Gugelhupf
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).Citation:
Envoyé par Flob90
Je remercie de tout cœur JolyLoic pour les précisions apportées :ccool: !
Je donnerai mon avis personnel dans un prochain post :).
Ah ben ca rassure un peu ca :DCitation:
Envoyé par JolyLoic
Voici donc mon avis personnel sur ces ajouts :
Oui ! Je dis oui ! Enfin !Citation:
lambdas génériques
Ça ça va grandement simplifier l'utilisation des lambdas. On va pouvoir faire voyager des unique_ptr par exemple :D.Citation:
capture généralisée par move
Oui, parfois ça manque.Citation:
les std::dynarray et Runtime-Sized Arrays
Un joli sucre syntaxique, qui néanmoins ne fait de tord à personne :).Citation:
les templates de variable
Ç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).Citation:
des réductions des utilitaires de traits
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 :).Citation:
des contraintes moindres pour les fonctions constexpr
Là oui, ça peut être pratique, pour les unique_ptr notamment.Citation:
std::exchange
Tout ce qui peut améliorer les iostream est bon à prendre. Et quoted est un bon début :).Citation:
std::quoted
J'utilise déjà pas de mutex, je n'utiliserai probablement pas plus celle-ci ^^.Citation:
les std::shared_mutex
Bon à prendre. Les tuples/pair qui prennent cette place ne sont pas aisés à manipuler (ni fantastiques question sémantique).Citation:
std::optional
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.Citation:
des user-defined literals dans la STL
Ça c'est bien dommage que ça soit nécessaire pour bug-fix.Citation:
std::make_unique
Les malloc les débutants connaissent plus, bientôt même le new ils connaîtront plus :mouarf:. Bon l'uniformisation c'est sympa... mais, le nombre de auto va encore exploser. Mais j'y reviens.
Ç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.Citation:
la déduction de type retour
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 :).
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.Citation:
Envoyé par germinolegrand
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.Citation:
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 :).
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.Citation:
Là oui, ça peut être pratique, pour les unique_ptr notamment.
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?Citation:
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.
J'ai pas compris de quel bugfixe tu parles?Citation:
Ç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 :mouarf:. Bon l'uniformisation c'est sympa... mais, le nombre de auto va encore exploser. Mais j'y reviens.
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).Citation:
Ç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.
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.
C'est clair.Citation:
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.
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 :aie: ) 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.Citation:
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.
Pareil :DCitation:
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 :).
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 ?Citation:
Envoyé par JolyLoic
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é ? :P
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 ? :P
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.
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".Citation:
Envoyé par Arzar
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.Citation:
Envoyé par Arzar
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.
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.Citation:
Envoyé par Arzar
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.
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 :D) sans impact sur les fonctionnalités existantes de l'espace de noms "parent".Citation:
Envoyé par germinolegrand
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 :D)...
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 ;)
:koi: 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).Citation:
Envoyé par koala01
Je l'espère de tout coeur. J'utilise C::B (pour son multiplateforme).Citation:
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.
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
Egalement disponible, l'initialisation des variables lors de la capture :Code:auto f() { return 42; } // return type is int
Et les tableaux de tailles variables mais fixe :)Code:[x = 42]{ ... };
Code:
2
3
4
5
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)
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).Citation:
Envoyé par gbdivers
La nouveauté est plutôt de pouvoir écrire :
Ce qui n'est pas si avantageux sauf quand les types sont compliques :Code:
2
3
4
Ou encore plus quand il est difficile de le connaître à la compilation statiquement :Code:
2
3
4
Code:
2
3
4
5
Tu as mal lu , Loïc :)
(j'ai édité mon code pendant que tu tapais ton message ;))
Ya aussi std::dynarray?Citation:
Envoyé par gbdivers