À partir de maintenant, seules les corrections mineures pourront être effectuées et Herb Sutter estime que la version finale sortira en 2011.
La norme ayant été élaborée en collaboration proche avec les implémenteurs, la plupart des compilateurs sur le marché ont intégré partiellement la nouvelle norme, certains ajouts à la bibliothèque standard bénéficient même d'une implémentation dans la célèbre collection de bibliothèques Boost dans un espace de nom distinct. Après le retrait des concepts qui devaient faciliter le développement des templates dû à la complexité d'implémentation, quelques petits changements :
- Retrait de la fonctionnalité "export template", le seul compilateur intégrant celle-ci étant Comeau et quasiment personne ne l'utilise, il a été décidé de la supprimer pour soulager la tâche des implémenteurs ;
- Ajout du mot clé "noexcept" pour compléter la dépréciation des déclarations d'exceptions. Cela devrait aider le compilateur à effectuer certaines optimisations.
C++0xB apporte une syntaxe simplifiée :
- Fini le petit espace entre les deux chevrons fermants quand on imbrique deux classes génériques. Amélioration mineure, mais appréciable ;
- Les fonctions lambda (appelées closures dans certains langages) qui devraient profiter, entre autres, à l'utilisation des algorithmes et des bibliothèques de traitements parallèles comme Intel TBB ;
- Les listes d'initialisations pour les conteneurs ;
- Boucle type foreach ;
- Union non restreinte aux types POD ;
- Prise en charge d'unicode ;
- etc.
Mais également un enrichissement de la bibliothèque standard :
- Nouveaux conteneurs : tuples, tables de hachages ;
- Pointeurs habiles (type Boost) ;
- Expressions rationnelles, threads, etc.
Pour la petite anecdote, C++0xB devait sortir dans la première décennie du troisième millénaire, mais au vu des retards, il a été suggéré avec humour d'utiliser une notation hexadécimale.
Il est probable que le nom final de la norme soit tout simplement C++11.
Aller plus loin
- Annonce sur le blog d'Herb Sutter (3 clics)
- Retard dans la norme (1 clic)
- Présentation de C++0xB sur wikipedia (22 clics)
# C++, un langage moderne ?
Posté par Bruno Michel (site web personnel) . Évalué à 6.
[^] # Re: C++, un langage moderne ?
Posté par Graveen . Évalué à 7.
à l'énorme détail prés que ce genre de révision me donne envie d'y revenir (ou de me me réorienter dessus, plutôt).
C++ c'est quand même... bah C++ quoi !
[^] # Re: C++, un langage moderne ?
Posté par Tonton Benoit . Évalué à 3.
Mais son implémentation au niveau du langage est une bonne chose, ça fera moins bidouille et sera peut-être un peu plus performant. J'espère juste que la syntaxe sera proche de celle utilisé par Qt, elle est bien foutue et ça me fera moins de travail pour le portage :p
[^] # Re: C++, un langage moderne ?
Posté par GeneralZod . Évalué à 4.
[^] # Re: C++, un langage moderne ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: C++, un langage moderne ?
Posté par Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: C++, un langage moderne ?
Posté par whity . Évalué à 2.
Après, moche et verbeux ?
std::for_each(list.begin(), list.end(), f);Pour comparaison, en C#
foreach(T item in list) f(item);Pas une grosse différence. On pourrait certes faire mieux avec des range plutôt que des itérateurs, mais la STL ne les a pas, alors on fait sans. Et côté approche, cela me semble nettement plus propre que l'approche C# (qui en plus, introduisait au départ des downcasts à tire-larigot du fait de l'implémentation de l'interface IEnumerable).
Le BOOST_FOREACH a l'avantage de permettre de mettre du code entre { }, et l'inconvénient, comme toute macro, de déconner grave avec les templates.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: C++, un langage moderne ?
Posté par Troy McClure (site web personnel) . Évalué à 5.
[^] # Re: C++, un langage moderne ?
Posté par Fabimaru (site web personnel) . Évalué à 1.
[^] # Re: C++, un langage moderne ?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
[^] # Re: C++, un langage moderne ?
Posté par GeneralZod . Évalué à 10.
Une expression régulière est une expression qui obéit à certaines règles de construction, c'est correct en Français et c'est finalement bien plus proche du terme original.
[^] # Re: C++, un langage moderne ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
- « clôture » quand on parle de la clôture transitive d'une relation ;
- « fermeture » quand on parle d'un pointeur de code avec un environnement (ce qui est présentement le cas).
Alors « les fonctions lambda (appelées closures dans certains langages) » c'est ignoble à lire, même si l'anglais est bien un langage…
Merci de corriger ça aussi…
(Et encore… déjà que « fonction lambda » c'est pas terrible…)
[^] # Re: C++, un langage moderne ?
Posté par Antoine . Évalué à 2.
[^] # Re: C++, un langage moderne ?
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: C++, un langage moderne ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: C++, un langage moderne ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Je ne vois pas la proximité. J'y vois justement plus la fermeture (non transitive) de l'environnement.
[^] # Re: C++, un langage moderne ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Je pense que tu es plus avancé que moi en mathématique. Du coup, tu donnes un autre sens au mot « fermeture », et donc tu n'es pas choqué par son emploi pour les closures. Alors que pour moi, une fermeture, ça reste un loquet, une tirette, une poignée de porte, etc.
[^] # Re: C++, un langage moderne ?
Posté par defmonkey . Évalué à 5.
Bof, tout ça (ou presque) existe depuis bien longtemps. Pas dans la bibliothèque standard, mais dans des bibliothèques (Boost, PCRE, etc.) qui sont disponibles depuis fort longtemps. Note aussi que les regexp sont dans l'API C Posix depuis moultes temps déjà (man regex).
«je trouve le moratoire de 2 ans de Python déjà bien assez long comme ça»
En ce qui concerne l'évolution des langages, je dois dire que c'est vraiment le contraire que j'affectionne: la stabilité. L'évolution permanente me semble plus relever de l'aveu (mon langage est mal b...) que de l'innovation.
Oui à l'évolution des bibliothèques standards quand des manques flagrants se font sentir (le réseau en Lisp, par ex ;), non à l'évolution permanente des langages.
[^] # Re: C++, un langage moderne ?
Posté par barmic . Évalué à 6.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C++, un langage moderne ?
Posté par Bruno Michel (site web personnel) . Évalué à 6.
Je vais prendre un exemple : « Fini le petit espace entre les deux chevrons fermants quand on imbrique deux classes génériques. » Ça me semble aberrant que l'on ait du attendre 10 ans (sûrement plus, en fait) pour corriger ça. Quand je pense au nombre de développeurs qui ont oublié cette espace et qui n'ont qu'un message d'erreur totalement incompréhensible, perdant pas la même occasion un bon paquet d'heures, c'est vraiment un gaspillage incroyable.
[^] # Re: C++, un langage moderne ?
Posté par NanoTech . Évalué à 5.
Par contre, les changements à la python sont beaucoup plus gênants, parce qu'ils changent la signification du code silencieusement (même aux mises à jour mineures), et que ça ne peut se révéler que dans des cas de code rarement exécuté, du coup, on risque de ne même pas voir de Warning durant les deux ans de transition.
Sans compter l'aberration d'avoir un langage qui forke de lui même (python 2.6 vs python 3). Dès que plusieurs projets ou librairies doivent interagir, c'est le cauchemar.
Pour la programmation système, je suis toujours fan du C90. Au moins, ça compile partout sans incompatibilité artificielle.
[^] # Re: C++, un langage moderne ?
Posté par Antoine . Évalué à 3.
Même aux mises à jour mineures ? Tu as un exemple ?
Sans compter l'aberration d'avoir un langage qui forke de lui même (python 2.6 vs python 3)
Ce n'est pas une aberration. Quand il y a des choses à corriger ou améliorer et que cela nécessite de casser la compatibilité, il faut bien s'y résoudre un jour.
Au contraire, forker est assez propre dans la mesure où cela signale bien la rupture de compatibilité.
[^] # Re: C++, un langage moderne ?
Posté par NanoTech . Évalué à 2.
À toutes les versions, il y a un changelog très bien fait.
Même immédiatement après une mise à jour majeure, des changements rétro-incompatibles sont faits:
Par exemple, le changement des règles de visibilité des variables dans python 2.1:
http://docs.python.org/whatsnew/2.1.html#pep-227-nested-scop(...)
Les autres versions aussi ont fait des changements incompatibles.
2.6 a supprimé les exceptions chaîne de caractères.
2.5 à supprimé la possibilité de renvoyer None dans __reduce__ (module pickle).
2.4 a changé le module email de telle sorte qu'aucune exception n'est lancée en cas de message mal formé parce qu'il ne décode pas tout d'un coup, mais utilise maintenant l'attribut defect pour signaler les erreurs au moment où il les rencontrent...
2.2 a changé la règle de recherche des méthodes en cas d'héritage multiple avec problème du diamant.
Ces incompatibilités touchent habituellement très peu de code, mais, à cause de la nature dynamique du langage, et de la subtilité des modifications, elles peuvent être silencieuses. Par exemple, un filtre de mailing list chargé de vérifier la validité des messages va silencieusement ignorer les erreurs à la 2.4.
Ce n'est pas une aberration. Quand il y a des choses à corriger ou améliorer et que cela nécessite de casser la compatibilité, il faut bien s'y résoudre un jour.
C'est une idée séduisante sur le plan théorique, mais, en pratique, ça divise la communauté en deux clans incompatibles. C'est pire que la division perl/ruby/python parce que ces langages étant clairement incompatibles, les communautés sont mieux séparées et on ne risque pas de mélanger du code accidentellement, vu qu'ils ont un syntaxe très différente.
La migration au 3 ne fournissant aucun retour sur investissement, les entreprises ne la feront qu'à contrecoeur, et uniquement quand la nécessité sans fera sentir.
On pourrait espérer que python 3 a supprimé d'un seul coup tout ce qu'il y avait de "mauvais" dans python 2.x, mais pas tout à fait, puisque dès python 3.0 ils sont prêts à déprécier une fonctionnalité en vue de la supprimer à la 3.2:
http://docs.python.org/dev/3.0/whatsnew/3.0.html#pep-3101-a-(...)
En fait, il semblerait qu'un bon rythme de dépréciation/suppression soit retenu pour python 3.x.
Je crois que les développeurs de python sous-estiment la taille de leur base d'utilisateurs et ne se rendent pas compte des conséquences socio-économiques du fork.
Sans compter le dilemme pour les nouveaux programmeurs: 2.x (plus large base installée, plus de librairies) ou 3.x (l'avenir, en théorie), mais on a pas toujours le choix (dépendance d'un librairie d'une tierce partie).
[^] # Re: C++, un langage moderne ?
Posté par Antoine . Évalué à 2.
Pour moi Python 2.1 n'est pas une version mineure, c'est une version majeure.
Par version mineure, j'entends par exemple le passage de la 2.6.4 à la 2.6.5.
C'est une idée séduisante sur le plan théorique, mais, en pratique, ça divise la communauté en deux clans incompatibles.
Je ne vois rien de tel dans la communauté, justement. Les similitudes sont assez grandes entre 2.x et 3.x pour que les gens continuent à échanger sans souci.
mais pas tout à fait, puisque dès python 3.0 ils sont prêts à déprécier une fonctionnalité en vue de la supprimer à la 3.2:
C'est un cas particulier. La nouvelle syntaxe de formatage de chaîne est un serpent de mer. Au début il était en effet prévu que l'ancienne meure totalement, mais cela a été repoussé aux calendes grecques.
Je crois que les développeurs de python sous-estiment la taille de leur base d'utilisateurs et ne se rendent pas compte des conséquences socio-économiques du fork.
Je ne pense pas, non. C'est un choix délibérément fait, pour introduire une version du langage plus agréable à utiliser. C'est aussi parce que la base d'utilisateurs n'est pas sous-estimée que le choix a été fait de ne pas repartir depuis zéro, mais simplement de faire les modifications les plus importantes. Les connaissances nécessaires pour développer avec la 2.x ou la 3.x ne sont pas significativement différentes, on s'en sort très bien en pratique.
Du reste, si la tendance continue, la base d'utilisateurs sera encore plus grande d'ici quelques années, lorsque (on l'espère) les versions 3.2/3.3 seront devenues les versions de choix pour développer.
# D'autres gros ajouts
Posté par Étienne . Évalué à 9.
- La gestion des threads dans le langage et la bibliothèque standard
- Les variadic templates qui doivent rendre des choses comme boost::mpl ou les typelist de Loki beaucoup plus simple.
- Les rvalue reference qui permettent de "déplacer" un objet dans un autre et, par exemple, éviter une copie du type de retour et permettre ainsi de retourner un objet non copiable.
Et pas mal d'autres choses, l'article de wikipedia en anglais est plus fournit que celui en français (http://en.wikipedia.org/wiki/C%2B%2B0x )
Étienne
[^] # Re: D'autres gros ajouts
Posté par Troy McClure (site web personnel) . Évalué à 7.
[^] # Re: D'autres gros ajouts
Posté par whity . Évalué à 6.
Mais ça n'empêche absolument pas de l'utiliser au jour le jour, puisqu'on a rarement besoin de toutes ces petites subtilités (et que, non, ces subtilités ne jouent pas contre nous si on ne s'en sert pas).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: D'autres gros ajouts
Posté par Guillaume Knispel . Évalué à 4.
[^] # Re: D'autres gros ajouts
Posté par alice . Évalué à 6.
Je regrette juste deux choses :
- l'abandon des 'concepts' qui aurait énormément simplifier le langage.
- rien n'est fait pour remplacer l'antique couple entête / #include par un système moderne de modules.
[^] # Re: D'autres gros ajouts
Posté par barmic . Évalué à 4.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: D'autres gros ajouts
Posté par Troy McClure (site web personnel) . Évalué à 4.
[^] # Re: D'autres gros ajouts
Posté par Gniarf . Évalué à 3.
[^] # Re: D'autres gros ajouts
Posté par lasher . Évalué à 2.
[^] # Re: D'autres gros ajouts
Posté par Guillaume Knispel . Évalué à 1.
Aussi utile pour faire les transformations syntaxiques fort utiles si les langages imposent une syntaxe lourde (ex : manque de littéraux)
[^] # Re: D'autres gros ajouts
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: D'autres gros ajouts
Posté par whity . Évalué à 2.
Mais ils auraient aussi complexifié l'écriture de ces templates (pas grave, c'est le boulot des développeurs de librairie, qui ont un niveau technique dans le langage supérieur à la moyenne), et surtout, ils entraînaient une énorme complexification des compilateurs.
Les développeurs vont devoir continuer d'apprendre à lire les messages d'erreur de leur compilateur, qui cela dit ont énormément progressé depuis et sont maintenant relativement utilisables.
Pour les modules, je crois qu'on peut rêver : vu le succès qu'a eu export, c'est mort. C pourrait probablement le faire, mais pour C++ et son système de templates, l'expérience a prouvé que ça apportait plus de mal qu'autre chose. Et il y a tellement de code existant qui a besoin du préprocesseur, les développeurs y sont tellement habitués, que ça n'a guère d'intérêt.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: D'autres gros ajouts
Posté par Étienne . Évalué à 2.
Normalement, dans la prochaine de version de GCC (4.5) les messages d'erreurs n'afficheront plus les paramètres template par défaut (cf http://gcc.gnu.org/gcc-4.5/changes.html : When printing the name of a class template specialization, G++ will now omit any template arguments which come from default template arguments.)
Étienne
[^] # Re: D'autres gros ajouts
Posté par alice . Évalué à 2.
Il ne faut pas forcément remplacer le préprocesseur, mais le système est une horreur et on est obligé d'utiliser tout un tas de techniques (pimpl, forward declaration dans tous les sens, classes virtuelles pures, factory) même pour des classes simples dès qu'on veut faire une API propre.
[^] # Re: D'autres gros ajouts
Posté par whity . Évalué à 1.
Tu peux détailler un peu ? Parce que personnellement, je n'ai pas de problèmes avec ça (sauf, dans une certaine mesure, les forward declaration. Mais souvent, s'il y a trop de forward declarations, c'est qu'il y a trop d'interdépendances --> peut-être que la conception est à revoir ?)
Les classes virtuelles pure, la factory, ça relève du design (pImpl aussi d'ailleurs, quoique c'est plus discutable). Ca n'a rien à voir avec la "propreté" de l'API que tu exposes. La seule chose que je vois qui pourrait manquer à un développeur habitué à java ou csharp, c'est la notion de "package" et la visibilité "internal". Mais je suis dubitatif sur son intérêt (C++ a friend pour les cas où c'est utile).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: D'autres gros ajouts
Posté par alice . Évalué à 2.
- on ne peut pas ajouter une variable membre privée à une classe sans casser la compatibilité binaire.
- si les types des membres privés viennent d'une bibliothèque, l'utilisateur de ma classe doit posséder les entêtes cette bibliothèque.
On peut toujours s'en sortir et un bon design permet d'éviter ces problèmes.
Mais c'est assez pénible au quotidien.
[^] # Re: D'autres gros ajouts
Posté par whity . Évalué à 0.
Je comprends mieux pourquoi tu parlais de pimpl. Effectivement, on ne peut pas changer la taille d'un objet sans casser la compatibilité binaire, sauf à ce que les clients n'utilisent que des pointeurs vers ces objets (auquel cas, rajouter un membre à la fin ne casse rien). C'est un peu le lot de tous les langages compilés, cela dit...
- si les types des membres privés viennent d'une bibliothèque, l'utilisateur de ma classe doit posséder les entêtes cette bibliothèque.
Ca dépend, là aussi, si les types sont inclus tels quels, oui, si ce sont des références ou des pointeurs, une forward declaration suffit. C'est toujours le même problème de taille d'objet, qui doit être connue pour tout module utilisant l'objet.
Je ne crois pas qu'il y ait de solution à ce problème (celle de java/c# n'en est pas une, c'est vraiment une approche différente).
Après, tout dépend du contexte. Personnellement, ça n'a jamais été un problème (forcer tous les utilisateurs de mon code à recompiler n'a jamais été une grosse contrainte, ça l'est par contre pour celui qui fait des bibliothèques).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: D'autres gros ajouts
Posté par alice . Évalué à 4.
Sauf Objective C, Java, C# et probablement d'autres.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.