Débat : Quel va donc être l'avenir du C++ ?
Le 2006-01-10 13:24:01, par Aurelien.Regat-Barrel, Expert éminent sénior
Dans l'article A Brief Look at C++0x, Bjarne Stroustrup (le créateur du C++) s'exprime sur l'avenir de ce langage. Rappelons que C++0x est le "nom de code" de la prochaine norme du langage qui est à l'étude depuis un certain temps déjà (voir Qu'est-ce que C++0x ?).
Dans son article, Bjarne explique que cette norme est entrée dans "une phase décisive" en vue de sa ratification en 2008. Il explique aussi que l'esprit de cette future norme est davantage de modifier la façon qu'ont les programmeurs de concevoir leur code plutôt que leur manière de l'écrire.
Une des priorités est de limiter l'introduction de nouveautés du langage au profit d'un enrichissement de la bibliothèque standard, dans un esprit de généricité, de simplicité et bien sûr de performance.
Bjarne effectue ensuite un rapide tour d'horizon des nouveautés. Il sera ainsi possible d'initialiser statiquement un conteneur avec une liste d'initialisation (au moyen de ce qui sera vraisemblablement un constructeur de séquence):
de définir un alias sur des templates (template typedef):
l'utilisation des conteneurs de la STL sera simplifiée afin de ne plus exiger un itérateur de début et un autre de fin:
ceci sera rendu possible grâce à une des grande nouveautés de C++0x : l'introduction des concepts, qui permettent de décrire le type d'un type (ses propriétés). Cela se traduit notamment par l'apparition du mot-clé where dans les templates qui permet de spécifier clairement des conditions sur le paramètre T passé.
Une autre grande nouveauté fort appréciable est la nouvelle signification du mot-clé auto (qui n'a actuellement plus d'utilité) : il permettra dans une déclaration de déduire automatiquement le type d'une variable à partir de son initialiseur.
Ainsi, l'utilisation des itérateurs de la STL sera fortement allégée. Au lieu d'écrire:
on pourra simplement écrire:
La bibliothèque standard va elle aussi être fortement enrichie, avec l'apparition
En revanche le C++ ne comportera toujours pas de bibliothèque graphique standard, mais pourrait disposer d'un garbage collector et d'une gestion des threads. Les développeurs sur systèmes embarqués ne sont pas non plus oubliés, avec l'apparition d'une bibliothèque facilitant l'utilisation directe du matériel.
Dans son article, Bjarne explique que cette norme est entrée dans "une phase décisive" en vue de sa ratification en 2008. Il explique aussi que l'esprit de cette future norme est davantage de modifier la façon qu'ont les programmeurs de concevoir leur code plutôt que leur manière de l'écrire.
Une des priorités est de limiter l'introduction de nouveautés du langage au profit d'un enrichissement de la bibliothèque standard, dans un esprit de généricité, de simplicité et bien sûr de performance.
Bjarne effectue ensuite un rapide tour d'horizon des nouveautés. Il sera ainsi possible d'initialiser statiquement un conteneur avec une liste d'initialisation (au moyen de ce qui sera vraisemblablement un constructeur de séquence):
Code : |
1 2 3 4 5 6 7 | class A {}; std::vector<A*> v = { new A, new A, new A }; |
Code : |
1 2 | template<class T> using Vec = vector<T,My_alloc<T>>; Vec<double> v = { 2.3, 1.2, 6.7, 4.5 }; |
Code : |
sort( v ); // remplace sort( v.begin(), v.end() );
Code : |
1 2 3 | template<Container C, Predicate Cmp> where Can_call_with<Cmp,typename C::value_type> // mot-clé where void sort(C& c, Cmp less); |
Ainsi, l'utilisation des itérateurs de la STL sera fortement allégée. Au lieu d'écrire:
Code : |
1 2 | for (std::vector<double>::const_iterator p = v.begin(); p!=v.end(); ++p) cout << *p << endl; |
on pourra simplement écrire:
Code : |
1 2 | for (auto p = v.begin(); p!=v.end(); ++p) cout << *p << endl; |
La bibliothèque standard va elle aussi être fortement enrichie, avec l'apparition
- des tables de hachage
- des expressions régulières
- de pointeurs intelligents plus complets
- de fonctions mathématiques spéciales
En revanche le C++ ne comportera toujours pas de bibliothèque graphique standard, mais pourrait disposer d'un garbage collector et d'une gestion des threads. Les développeurs sur systèmes embarqués ne sont pas non plus oubliés, avec l'apparition d'une bibliothèque facilitant l'utilisation directe du matériel.
-
PRomu@ldExpert éminentVoilà qui va redonner un bon coup de fouet au langage. J'ai hate de pouvoir tester ces nouveautés.En revanche le C++ ne comportera toujours pas de bibliothèque graphique standard
Un autre papier sur ces évolutions :
http://public.research.att.com/~bs/rules.pdfle 10/01/2006 à 21:03 -
AlpExpert éminent séniorAh une bonne nouvelle, quand même.
Ces nouveaux features ont l'air pratiques et bien faits.
Il restera tout de même à voir de quoi il en retourne!
Dommage pour l'interface graphique, mais après tout depuis le temps il y en a qui sont sorties, faites en C++ et faciles à installer et probablement aussi complètes qu'aurait pu l'être celle de la STL.le 10/01/2006 à 21:12 -
JolyLoicRédacteur/ModérateurPour ceux qui veulent suivre ça de plus près, il y a moyen d'avoir accès direct aux propositions d'évolution :
http://www.open-std.org/jtc1/sc22/wg...1/docs/papers/
Le papier de Bjarne est une bonne vulgarisation des évolutions qui ont de très bonnes chances de passer, mais il n'entre pas vraiment dans les détails.le 10/01/2006 à 21:35 -
HRSMembre confirmél'ennui est qu'il va falloir attendre
-que la nouvelle norme C++0x soit définitive
-qu'elle soit implantée sur tous les compilateurs (voir C99)
Il serait désastreux, en effet, de faire un développement dans un
environnement doté d'un compilateur top-niveau mais que le portage
soit impossible parce que les environnements cibles aient, eux, un
compilateur implantant partiellement ou pas du tout, la nouvelle
norme
Qui va prendre un tel risque ?le 11/01/2006 à 12:49 -
Jean-Marc.BourguetExpert éminent
Envoyé par HRS le 11/01/2006 à 14:10 -
tutMembre avertiBjarne justifie l'absence de bibliothèque graphique par deux raisons :
Les personnes faisant partie du comité n'ont pas assez de temps pour spécifier une telle bibliothèque,
Les bibliothèques éxistantes profitent d'un support communeautaire et d'un passé qui fait qu'elles sont viables.
Personellement je trouve ça plutôt pas mal d'avoir le choix, et puis quand on voit les interfaces graphiques "standard Java".... enfin, ce n'est que mon point de vue.le 12/01/2006 à 14:18 -
AlpExpert éminent séniorPour les interfaces graphiques:
en effet l'interface standard java est ... hum ... enfin on trouve bien mieux...
Et puis oui avoir le choix c'est bien, surtout quand on voit des bibliothèques bien faites comme wxWidgets,QT,GTK(+), et bien d'autres.
Pour la "normalisation" du C++0x:
Peut-être au début ce sera dur de passer sur toutes les plateformes, le temps qu'elles se standardisent, mais pour peu qu'une nouvelle version de g++ sorte, ca fera déjà bouger les choses!
Une question qu'on peut se poser est : Microsoft va-t-il suivre le mouvement et sortir un nouveau Visual C++? si oui, au bout de combien de temps?
De même chez Borland...le 12/01/2006 à 16:52 -
JolyLoicRédacteur/ModérateurMicrosoft, après avoir été un moment en retrait du C++, y est revenu assez fortement (embauche de gouroux, respect de la norme de 1998...) vers 2002.
A mon avis, le problème est désormais inverse : Ils investissent fortement dans leurs propres extentions de la norme, pour faire ce qu'ils appellent C++/CLI, et la question se pose de la façon dont ces extentions (qu'ils veulent par ailleur normaliser) se positionnent par rapport au C++.le 12/01/2006 à 21:15 -
Aurelien.Regat-BarrelExpert éminent séniorMicrosoft a fait des propositions pour la future norme (le template typedef par exemple, c'est eux, ou encore les enum fortement typés). A l'inverse ils freinent des pieds sur certains points (template export).
Ils devraient donc suivre sur pas mal de points quand même. On trouve des interview (de Sutter en particulier) sur channel9, mais je ne les ai pas regardé. Je pense que c'est un peu trop tôt de toutes façons pour avoir des infos.
Et d'ici 2008/2010, il peut se passer pas mal de choses. Je pense entre autre au développement 64 bits. On le voit émerger, mais on n'est pas nombreux à y avoir gouté. Je pense que ça aura changé d'ici là. Un PC possède maintenant courament 1 voire 2Go de RAM. La limite plysique est à 4Go, mais moins que ça en réalité (par défaut 2 Go pour les applications sous Windows, on peut monter à 3 Go). Donc cette année on va arriver à saturer la mémoire 32 bits. Dans 3 ans, ça risque bien de devenir un problème, et les PC + OS 64 bits devraient commencer à se répandre. Et va falloir tout basculer...
Ca + l'arrivée de Windows Vista, je ne pense pas que C++0x soit la priorité immédiate des développeurs de VC++.le 13/01/2006 à 11:05 -
Jean-Marc.BourguetExpert éminent
Envoyé par Aurelien.Regat-Barrel
Je ne concluerais rien a propos de Microsoft en general a partir de l'action de quelques un de ses employes dans le comite. Surtout quand leur participation au comite est anterieure a leur engagement par Microsoft.
Je suis d'ailleurs certain que l'action de Microsoft, pour autant qu'elle soit coherente et concertee sur ce sujet ce dont je suis pas sur, est plus le fruit d'un compromis entre courants differents a l'interieur de Microsoft qu'autre chose.Et d'ici 2008/2010, il peut se passer pas mal de choses. Je pense entre autre au développement 64 bits. On le voit émerger, mais on n'est pas nombreux à y avoir gouté. Je pense que ça aura changé d'ici là. Un PC possède maintenant courament 1 voire 2Go de RAM. La limite plysique est à 4Go, mais moins que ça en réalité (par défaut 2 Go pour les applications sous Windows, on peut monter à 3 Go). Donc cette année on va arriver à saturer la mémoire 32 bits. Dans 3 ans, ça risque bien de devenir un problème, et les PC + OS 64 bits devraient commencer à se répandre. Et va falloir tout basculer...
Quelles sont les applications sur un PC qui ont reellement besoin du 64 bits? J'ai un ordinateur 64 bits depuis des annees sur mon bureau. Hors nos applications, le seul programme dont j'ai eu besoin en 64 bits a ete emacs pour arriver a lire des gros fichiers.le 13/01/2006 à 14:18