Discussion :

[Aurelien.Regat-Barrel]

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):

Code :

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

1
2
3
4
5
6
7
class A {};
 
std::vector<A*> v = { 
    new A,
    new A,
    new A
};

de définir un alias sur des templates (template typedef):

Code :

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

1
2
template<class T> using Vec = vector<T,My_alloc<T>>;
Vec<double> v = { 2.3, 1.2, 6.7, 4.5  };

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:

Code :

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

sort( v ); // remplace sort( v.begin(), v.end() );

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é.

Code :

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

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);

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:

Code :

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

1
2
for (std::vector<double>::const_iterator p = v.begin(); p!=v.end(); ++p)
    cout << *p << endl;

on pourra simplement écrire:

Code :

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

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

et de bien d'autres choses.

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@ld]

Voilà 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

Ce n'est pas bien grave je pense, au vu de ce que pourra apporter la nouvelle norme.

Un autre papier sur ces évolutions :

http://public.research.att.com/~bs/rules.pdf

[Alp]

Ah 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.

[JolyLoic]

Pour 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/wg21/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.

[HRS]

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 ?

[Jean-Marc.Bourguet]

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 ?

Ceux qui cherchent la portabilite (et j'en fais partie) definissent quelle portabilite ils desirent (on utilise g++ partout est une approche a mon sens valide mais pas sans inconvenients) et donc se limitent dans ce qu'ils utilisent. Rien n'a change. Je me souviens d'un projet ou on s'est demande "utilisera-t'on la STL?" maintenant presque personne ne se pose la question, et ceux qui se la pose ce n'est pas pour des raisons de disponibilite.

[tut]

Bjarne 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.

[Alp]

Pour 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...

[JolyLoic]

Microsoft, 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++.

[Aurelien.Regat-Barrel]

Microsoft 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++.

[Jean-Marc.Bourguet]

Microsoft 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).

export est deja dans la norme...

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...

Quel rapport entre le 64 bits et l'evolution du C++? Cela fait des annees qu'on developpe des applications 64 bits en C++ sans probleme, meme si ce n'est pas sur des PC.

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.

[Aurelien.Regat-Barrel]

export est deja dans la norme...

Oui, mais Sutter critique son existence, et envisage (il me semble) sa suppression dans la prochaine norme.

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.

Je n'ai pas cherché à positionner MS par rapport au C++, simplement dire que je voyais mal MS avoir d'un côté son nom associé à des propositions pour la norme, et d'un autre ne pas les intégrer dans ses prochaines versions de VC++ si elles sont acceptées (la question était "Microsoft va-t-il suivre le mouvement ?").

Quel rapport entre le 64 bits et l'evolution du C++? Cela fait des annees qu'on developpe des applications 64 bits en C++ sans probleme, meme si ce n'est pas sur des PC.

Par rapport à VC++ toujours. Chaque version généralement se focalise sur un point "maketing". VC++ 7 c'était .Net, VC++ 7.1 le respect de la norme C++, VC++ 8 C++/CLI. Il faut bien susciter l'achat.
Je voulais dire que "respect de C++0x", ça ne sera sûrement pas pour VC++ 9, ils vont avoir / trouver d'autres priorités d'ici là.

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.

Je pense pareil. J'ai 2 Go de mémoire, et c'est 2 fois trop. Mais dans 3/5 ans...

[Jean-Marc.Bourguet]

export est deja dans la norme...

Oui, mais Sutter critique son existence, et envisage (il me semble) sa suppression dans la prochaine norme.

A ma connaissance, il a ete decide que ce n'etait meme pas un sujet de discussion.

Au fait, si tu veux voir quelles ont ete les reactions a ce papier, il y a un thread sur fr.comp.lang.c++ ou il est intervenu.

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.

Je pense pareil. J'ai 2 Go de mémoire, et c'est 2 fois trop. Mais dans 3/5 ans...

Je n'ai pas parle de la memoire totale de l'ordinateur, simplement des applications. La memoire totale gerable par Windows depasse deja les 4Go.

[Elendil_BzH]

Pas de programmation par contrats, pour l'instant, dans la nouvelle norme ? J'avais trouvé quelques documents sur le site open-std.org et j'avais bon espoir de retrouver ça dans la prochaine norme.

AMHA, c'est une des évolutions majeures que doit subir le langage, comme pour Java, qui devrait, apparemment, supporter la programmation par contrats dans une prochaine version.

Si quelqu'un a plus de précisions sur le sujet...

[Alp]

Sans vouloir jouer l'ignorant, je n'ai jamais vu de document ou quoique que ce soit d'autre qui explique ce qu'est "la programmation par contrats".
En quoi cela consoiste-t-il ?
Est-ce que le comité aurait ne serait-ce qu'envisagé de l'intégrer au C++ ?

[Jean-Marc.Bourguet]

Pas de programmation par contrats, pour l'instant, dans la nouvelle norme ? J'avais trouvé quelques documents sur le site open-std.org et j'avais bon espoir de retrouver ça dans la prochaine norme.

Il y a peu de choses où la décision est prise. A ma connaissance la proposition reste sur la table.

[Luc Hermitte]

Un bon bouquin, qui en traite, est normalement celui de Bertran Meyer.
Sinon, il me semble avoir croisé une série d'articles à ce sujet il y a peu. Sur artima, je crois. Sur fclc++, tu devrais trouver des discussions au sujet de comment on l'implémente en C++. Généralement, c'est James Kanze qui parle (et développe) d'une implémentation C++ de la notion de contrat.

[faressam]

Bonjour
En faite je me demande si il faut faire aussi une étude sur l'integration du developpement des applications C++ dans les entreprise ,est ce que ça sera délaisser ou c'est promoteur

[Kaktus]

faressam : c'est une bonne question ... surtout pour les petits et moyens projets où le C++ est beaucoup moins employé que Java, VB et autres. Chez moi c'est très net, (Limousin) voilà ce que j'ai constaté :
- pas une offre C/C++
- toute association/ coordinateur entreprise m'a répondu : Ecoutez, en C++, sur des petits projets comme les vôtres, je ne connais personne (sauf vous maintenant ) .. J'en ai fait il y a qques années mais bon.Encourageant.

Chez nous, à part PHP (qui est très très présent) et langages web, un peu de Java, windev et du VB, rien.

Je connais même une boîte qui développe en VB5 c'est pour dire ....

les arguments que j'entends :
- Ouh là c'est dur le C++ et ça sert à rien pour des petits trucs
- Ca marche pas ça plante tout le temps
- et surtout : pourquoi m'embêter avec des pointeurs alors que en 2 jours j'ai bouclé mon logiciel de compta en VB ? C'est pas rentable. J'ai pas envie de passer des mois à me faire mes classes même si c'est vrai qu'après le développement est plus rapide.
- UML? c'est quoi? (sic et véridique)


Quand on dit qu'on peut faire des tourner des logiciels (en MDI avec images de fond etc ...) sur 15Mo sur des PIII500 avec que des produits/ librairies libres (tant qu'à faire) on me regarde avec des yeux ébahis comme si j'étais un extra_terrestre (vous êtes sur que ça marche??? <-- ben oui j'en suis sûr )


J'ai l'impression qu'il y a eu un flottement pendant qques années, bon, avec la nouvelle norme et les derniers chiffres qui sont encourageant, les passionnés qui ne désarment pas et prouvent par A+B qu'un truc codé en C++ tient largement la route, il ne faut pas s'affoler qd mm.



Pour en avoir parlé avec des enseignants en info, on manque cruellement de personnes excellentes en C++, il faut au minimum 5ans de pratique pour y prétendre rien qu'en technique (sic), je compte mm pas l'UML, indispensable ...

Les cours dispensés dans les BTS et fac sont très légers en C/C++, il faut bien dire ce qui est, si on ne gratte pas tout seul, on ne fait rien dans ce langage et à moins d'un coup de foudre, c'est dur d'y passer des soirs à traquer un memory leak ...

Il y a aussi un problème de livres, parfois truffés d'approximations pour ne pas dire d'erreurs qui n'aident pas beaucoup.

Et puis le côté pratique :
En 2 ans de Java, on est excellent en java, en 2ans de C++ on est moyen ... Or l'enseignement à court terme se doit de former des gens tout de suite adaptés au marché.

Et enfin :
le C++ ne dispose pas des mêmes atouts financiers en terme de pub notamment auprès de l'enseignement du fait de son absence de droit d'auteur.


Voilà ce que j'en déduis actuellement. Pourtant, développer en C++ n'est pas plus long à moyen terme, quand les classes/ librairies sont faites on va aussi vite qu'en VB après. Seulement il faut se donner les moyens et ça trop peu de petites structures s'y osent car tout simplement c'est pas rentable et hasardeux à court terme.


Ce n'est que mon avis

[:Bronsky:]

Bonjour,

Ce sujet m'intéresse car je me pose justement pas mal de question en ce moment sur l'avenir de ce qui reste mon langage de prédilection... J'ai une petite question par rapport à ceci :

En revanche le C++ ne comportera toujours pas de bibliothèque graphique standard, mais pourrait disposer d'un garbage collector

J'ai beau réfléchir je ne vois pas en quoi un garbage collector serait utile au C++. Avec les pointeurs intelligents le C++ atteindra un niveau de fiabilité quant à l'acquisition/libération de ressources qui sera le même que Java ou C#, sans pour autant s'encombrer d'un garbage collector lent et à destruction non-déterministe... A partir de là, quelqu'un peut-il éclairer ma lanterne sur la valeur ajoutée d'une telle chose ??

De mon point de vue, le garbage collector est surtout cette chose maudite qui m'empêche d'implémenter l'idiome RAII quand je fais du Java ou du C#, car il ne détruit pas les objets au moment même où on sort de leur contexte d'utilisation... alors l'idée de le retrouver en C++ ne m'enchante guère