IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Débat : Quel va donc être l'avenir du C++ ?

Le , par Aurelien.Regat-Barrel

0PARTAGES

0  0 
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
1
2
3
4
5
6
7
class A {};

std&#58;&#58;vector<A*> v = &#123; 
    new A,
    new A,
    new A
&#125;;
de définir un alias sur des templates (template typedef):

Code : Sélectionner tout
1
2
template<class T> using Vec = vector<T,My_alloc<T>>;
Vec<double> v = &#123; 2.3, 1.2, 6.7, 4.5  &#125;;
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
sort&#40; v &#41;; // remplace sort&#40; v.begin&#40;&#41;, v.end&#40;&#41; &#41;;
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
1
2
3
template<Container C, Predicate Cmp>
    where Can_call_with<Cmp,typename C&#58;&#58;value_type> // mot-clé where
    void sort&#40;C& c, Cmp less&#41;;
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
1
2
for &#40;std&#58;&#58;vector<double>&#58;&#58;const_iterator p = v.begin&#40;&#41;; p!=v.end&#40;&#41;; ++p&#41;
    cout << *p << endl;

on pourra simplement écrire:

Code : Sélectionner tout
1
2
for &#40;auto p = v.begin&#40;&#41;; p!=v.end&#40;&#41;; ++p&#41;
    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.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de PRomu@ld
Expert éminent https://www.developpez.com
Le 10/01/2006 à 21:03
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
0  0 
Avatar de Alp
Expert éminent sénior https://www.developpez.com
Le 10/01/2006 à 21:12
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.
0  0 
Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 10/01/2006 à 21:35
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/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.
0  0 
Avatar de HRS
Membre confirmé https://www.developpez.com
Le 11/01/2006 à 12:49
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 ?
0  0 
Avatar de Jean-Marc.Bourguet
Expert éminent https://www.developpez.com
Le 11/01/2006 à 14:10
Citation Envoyé par 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 ?
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.
0  0 
Avatar de tut
Membre averti https://www.developpez.com
Le 12/01/2006 à 14:18
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.
0  0 
Avatar de Alp
Expert éminent sénior https://www.developpez.com
Le 12/01/2006 à 16:52
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...
0  0 
Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 12/01/2006 à 21:15
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++.
0  0 
Avatar de Aurelien.Regat-Barrel
Expert éminent sénior https://www.developpez.com
Le 13/01/2006 à 11:05
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++.
0  0 
Avatar de Jean-Marc.Bourguet
Expert éminent https://www.developpez.com
Le 13/01/2006 à 14:18
Citation Envoyé par 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).
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.
0  0