L'avenir du C++

Citation:

---

Envoyé par outs

Donc pas d'espoir de voir un changement dans le systeme des référence de C++ dans la prochaine version ?

---

Je n'ai pas compris quels changements tu voudrais...

Je n'ai pas connaissance de changement dans ce domaine, et je ne vois pas quel type de changement tu souhaits vraiment, ni pour quelles raisons...

Pourrais-tu poster un exemple pour clarifier ?

Citation:

---

Envoyé par JolyLoic

Je n'ai pas connaissance de changement dans ce domaine,

---

Il y a bien les "Rvalue References", mais je ne sais pas si ça correspond à ce qu'il veut.

Citation:

---

Envoyé par JolyLoic

Je n'ai pas connaissance de changement dans ce domaine

---

Merci de la réponse :)

Pouvoir écrire un truc de ce genre peut être ?

Code:

---

A & a = new B();

---

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Pouvoir écrire un truc de ce genre peut être ?

Code:

---

A & a = new B();

---

---

Et c'est censé vouloir dire quoi ?

Je conseille de consulter ce lien pour voir le statut actuel des différentes nouvelles fonctionnalités :
http://www.open-std.org/jtc1/sc22/wg...006/n1969.html

Il y a vraiment beaucoup beaucoup de choses nouvelles intéressantes.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Pouvoir écrire un truc de ce genre peut être ?

Code:

---

A & a = new B();

---

---

Quel est le probleme que ca resoudrait (on parlait aussi de complexite inutile, ajouter quelque chose augmente la complexite) que

Code:

---

A& a = *newB();

---

ne resouds pas?

Juste un mot à propos de "Comment comparer des languages"...

Bien sûr, c'est souvent une guerre de religion et pour faire court, mon opinion est qu'il faut maitriser plusieurs languages et choisir le plus adapté à la tâche.

Ceci étant dit, j'ai l'impression qu'on ne peut plus désormais évaluer un language sur ses seuls aspects intrinsèques. De plus en plus, je me dis que les outils existants pour ce language sont aussi importants. Il y a bien sûr les librairies (graphiques, mathématiques [e.g. FORTRAN, numerical recipes in C], réseau), la communauté et la doc. Mais il me semble qu'il faut aussi considérer l'IDE. Contrairement aux librairies, dont l'existence n'est conditionnée qu'à la taille de la communauté et l'ancienneté du langage, l'IDE est fortement lié au langage.

Prenons le cas d'Eclipse. J'entends beaucoup de gens dire qu'ils choisissent Java parce que Eclise pour Java est un vrai bonheur. L'IDE (pas seulement le langage) est multi-plateforme. Elle offre des fonctionnalités comme: code complétion, code assist (proposition de correction des erreurs [e.g. ajouts des import manquants, etc.]), refactoring, syntax highlighting très poussé (plus besoin de préfixer les variables private par _ car le highlighter peut les afficher dans une police différente). Et c'est *vraiment* incroyablement confortable! Et ca augmente fortement la vitesse de développement!

Or Eclipse pour C/C++ (plugin CDT) n'est pas aussi avancé. Une des raisons principales est que le langage est incroyablement plus compliqué à parser! Par exemple, avec le préprocesseur, il est possible de confondre un parseur sur les expressions bien parenthésées. Les template sont assez compliqués à interpréter. Il est possible d'écrire du code qui compile, bien qu'il contiennent des parties qui ne soient pas syntactiquement correcte :

Code:

---

1 2 3 4 5 6

#ifdef NEVER_DEFINED try (to [fontify this code) { ah!ah! ;-) } #endif

---

Il est aussi possible d'écrire du code dont on ne peut détecter certaines caractéristiques (e.g: la variable est elle private ou protected):

Code:

---

1 2 3 4 5 6 7

template <class T> public Foo : public T { public: void doit() { printf(this->variable); } // variable est public ou protected selon T ?!?! }

---

Bref, pour parser correctement, il faut grosso modo disposer d'un compilateur. Du coup, les outils de refactoring ou de code assist sont beaucoup plus compliqués à mettre en oeuvre. On y arrivera probablement (bravo CDT!) mais pour l'instant, on peut considérer que c'est un désavantage pour C++.

Les environnements de dev sont une autre guerre de religion tout aussi ancienne. Souvenez-vous vi vs emacs, ...
Mais effectivement, C++ souffre d'être un langage 100 plus complexe que le Java, et que donc les traitements intelligents nécessitent pratiquement un compilo. J'avais croisé deux trois projets d'analyse de code (et autre réflexivité) en C++. Je n'avais pas trop eu le temps de chercher à les exploiter pour ma suite de plugins pour vim.

Je ne vois pas ce qu'eclipse va changer là dedans. VS a une énorme avance en matière de compréhension du code. Ce qui n'empêche pas que des éditeurs vendent des plugins comme Visual Assist qui améliorent encore la situation.
Et côté édition pure, les vrais éditeurs comme emacs ou vim sont toujours loin devant -- il y a deux jours j'ai écris, pour vim, un générateur de switch-case à partir d'un énum C++ avec une facilité déconcertante.

L'erreur qui pourrait être commise, c'est de ne pas chercher à capitaliser le boulot déjà réalisé par d'autres et de tenter de tout redéfinir soit même.

Je souscris `a cette analyse ;-). Personnellement, je suis pour l'instant toujours plus rapide sous emacs que sous Visual ou Eclipse, même si je suis prêt à faire le passage (je m'accroche pas à une religion: je suis plutôt polytheiste pragmatique ;-)).

Étendre emacs (avec Lisp) ou vim (je maitrise pas le langage) est vraiment simple et on peut obtenir une customisation de son éditeur. Pour l'utilisateur lambda, c'est pas intéressant, mais pour le codeur, a terme, c'est un gain de vitesse *énorme*.

Ce que je n'arrive pas à savoir c'est si c'est fondamentalement une qualité d'emacs/vim/nedit/etc. ou si Visual/Eclipse peuvent tout aussi bien être customisés (VBA macros? Plugins?), simplement c'est beaucoup plus compliqué et seules des boîtes vendant des plugins (Visual Assist?) le font. Alors que pour emacs/vim, l'existant est immense car tout programmeur peut facilement customiser (c'est juste un éditeur, pas une usine à gaz). À noter qu'il existe des plugins VS qui permettent d'utiliser tout l'IDE avec un emacs intégré comme éditeur (http://www.atnetsend.net/computing/VisEmacs/)!!!

Mon post visait surtout à souligner que la complexité naturelle de C++ rend difficile l'analyse (automatique mais manuelle aussi) de code. Et que c'est un aspect à prendre en compte dans le choix d'un langage pour une tâche donnée.

Il existe des plug-ins pour Visual Studio, mais toutes les versions de l'IDE ne les supportent pas : les versions Express ne le permettent pas par exemple.

J'ai lu rapidement le "combat" eiffel/C++ et je le relance un peu....Je pense que le C++ aura toujours un avantage sur les langages "intégriste" type eiffel car il laisse au programmeur le choix de sa méthode.
Rien ne vous empêche de faire du pure objet en C++ (à part main évidemment...bon enfin si on chipote ;) )

Néamoins pour en revenir au sujet de la discussion, voilà quelques suggestions pour l'avenir du C++ :
- à quand un type chaine de caractère intégré au langage ? Je n'aime les type intégrés "façon VB" qui gâche l'aspect minimaliste du langage, mais allez expliquer à un débutant pourquoi :

Code:

---

string str = "salut" + " tout le monde";

---

ne marche pas alors que fonctionne :

Code:

---

string str = string("salut") + " tout le monde";

---

- pourquoi les référence ne sont elles pas reréférencable comme les pointeurs ? On pourrait introduire :

Code:

---

1 2 3 4

type& ref = object1; ref = value; // fixe la valeur d'object1 ref := object2; // maintenant ref reference object2

---

- le préprocesseur est encore trop présent en C++. La gestion de biblio est vraiment bordélique et inabordable pour un débutant : On devrait introduire un mécanisme simple de définition de librairie pour éviter les #ifndef etc, pour lier les en-tête au code binaire de la librairie correspondante Du genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

// Dans le .h : #librarie_header ma_bibli // le reste du .h ....   // Dans le .c définissant la bibli #library_code ma_bibli   // Dans un .c utilisant la bibli #using ma_bibli #using iostream

---

Je reconnais que mon exemple est reprochable et qu'il est difficile de simplifier sans limiter les options de compilations et autres. On devrait cependant s'inspirer des mécanismes de Java etc.

Du reste C++ reste un langage très fléxible et un des seuls à donner autant de libertés.

(C'est là que je regrette que phpBB (& fils) ne gère pas les fils de discussion comme on peut le faire via les clients NNTP.)
Pour ces histoires d'éditeurs, en vrac:
- les scripts pour vim sont codés en VimL (langage de script simpliste). Ruby, python, perl et un autre lanage qui ne revient pas peuvent être utilisés pour coder des scripts pour vim.
- ces vieux éditeurs s'étendent par des langages de script. Eclipse s'étend en Java, si mes souvenirs sont bons. Ce n'est ni le même boulot, ni la même rigueur qui sont attendus. Quand on utilise vim, on sait faire un certain nombre de choses à la main (substitutions avec regexs de folie, naviguer avec ctags, ...). Concevoir un plugin revient souvent à taper dans un fichier ces séquences que l'on maitrise et de les enrober avec des structures de contrôles. Je ne suis pas persuadé que l'on ait la même simplicité de définition de scripts pour eclipse ou VS. Je soupçonne le pas à faire plus conséquent dans la mesure où l'on ne manipule pas directement les fonctionnalités que l'on veut enrober depuis l'EDI (sans passer par souris et autres menus).
- Il y a un paradoxe à écrire des plugins eclipse en Java pour ... faciliter le développement en C++.


Concernant les références. Divers langages utilisent le même nom pour parler de choses différentes. Les références d'Eiffel, de Java, ... ne sont pas des alias (comme en C++), mais des super-pointeurs. Les réassocier ne correspond pas vraiment à ce qu'est destinée une référence.
S'il le faut avec beaucoup de magie à base de proxy, on peut en définir des réattachables. Mais si c'est juste pour remplacer -> par ., c'est pas important. Si c'est pour s'assurer de la validité des objets -> on peut définir des accesseurs qui renvoient des "références" en déréférençant un pointeur qui a survécu à un assert.

Pour les 2 autres critiques, j'admets volontier que la voie héritée du C n'est pas toujours la plus simple. Mais attention, on ne peut pas tout changer comme cela car :
- il y a des risques de casser du code existant
- cela revient à définir un tout nouveau langage.

Pour les histoires d'include, il y a des tentatives en cours (voir les propositions sur les sites d'évolution du C++), mais l'auteur a indiqué que ces propositions n'étaient pas une priorité pour lui actuellement. Il y a aussi un projet sponsorisé par boost et google visant à implémenter cet proposition afin de voir ce qu'elle donne dans la pratique. On peut donc espèrer.

Les choses se précisent.
Hop un petit lien -> http://herbsutter.spaces.live.com/bl...51BB!159.entry
(partial draft inside)

Ouah, j'aurais jamais pensé qu'ils considéreraient sérieusement cette suggestion que j'avais aperçue il y a quelque mois sur l'intégration d'un garbage collector.
Des remarques sur ce point?

Comme c'est facultatif, c'est bien.

Il ne cite que les fonctionnalités qu'il juge majeures et qui ne sont pas encore incluses dans le document de travail.

Personnellement, je regrette que le C++ nouveau n'intègre pas un mécanisme similaire aux packages du Java.

Après avoir programmé des années en Java et revenant actuellement au C++ pour ne pas perdre la main, je trouve le mécanisme des .h et des include proprement infernal.
Il y a en effet plusieurs inconvénients au mécanisme du C++ :
- Devoir placer des verrous #ifndef pour empêcher que le même code ne soit compilé plusieurs fois.
- Déclaration et définition séparée du code, donc je dois écrire les en-têtes deux fois, les classes sont sur deux fichiers, je dois veiller à leur cohérence, des méthodes peuvent apparaître dans le cpp sans être dans le .h, etc...
- Difficultés comme celles que j'ai évoquées ici:
http://www.developpez.net/forums/sho...d.php?t=300238

J'ai beau me creuser la tête, je ne trouve aucun avantage permettant de justifier celà.

Citation:

---

Envoyé par BugFactory

Personnellement, je regrette que le C++ nouveau n'intègre pas un mécanisme similaire aux packages du Java.

---

Je ne crois pas que quiconque défende l'utilisation du préprocesseur face à un vrai système de modules. La raison de la situation en C++ est historique. Introduire un vrai système de modules pose des problèmes de compatibilité. Il y a une proposition en cours, elle ne serait vraissemblablement pas dans la prochaine norme.

Citation:

---

Après avoir programmé des années en Java et revenant actuellement au C++ pour ne pas perdre la main, je trouve le mécanisme des .h et des include proprement infernal.
Il y a en effet plusieurs inconvénients au mécanisme du C++ :
- Devoir placer des verrous #ifndef pour empêcher que le même code ne soit compilé plusieurs fois.

---

Ce n'est pas si contraignant que cela.

Citation:

---

- Déclaration et définition séparée du code, donc je dois écrire les en-têtes deux fois, les classes sont sur deux fichiers, je dois veiller à leur cohérence, des méthodes peuvent apparaître dans le cpp sans être dans le .h, etc...

---

La séparation est pour moi un avantage. Mélanger l'interface de la classe avec son implémentation me semble un problème logique, même sans parler des dépendances introduites. J'aimerais bien un système où on n'a réellement à déclarer que l'interface (donc rien de ce qui est privé) de manière séparée de l'implémentation.

Citation:

---

- Difficultés comme celles que j'ai évoquées ici:
http://www.developpez.net/forums/sho...d.php?t=300238

---

Le fait que le corps des fonctions inline doivent être visibles, c'est une concession pragmatique. Mais il ne font pas partie de l'interface, donc leur place est ailleurs, dans un .ipp par exemple. Une fois fait, le problème est résolut naturellement.

Tous ces arguments sont valables.

Et pourtant on fait le même travail plus rapidement en Java.:P

C'est sûr, c'est tellement mécanique et bête à faire que ça en devient un peu chiant à faire à la main.

Mais c'est typiquement le genre de truc où l'éditeur de texte ou l'EDI devrait ou devrait pouvoir proposer automatiquement (et Visual C++ le fait automatiquement, je crois, mais avec un #pragma once au lieu de faire des #define).

Je pense que ça doit pas être compliqué à faire sous emacs ou vi, avec des macros.

Citation:

---

Envoyé par BugFactory

Tous ces arguments sont valables.

Et pourtant on fait le même travail plus rapidement en Java.:P

---

Si c'est le plus gros reproche que tu as a faire au C++, tu ne le connais pas assez.
Si c'est un facteur important dans ta productivite, c'est que tu ne maitrises pas assez les outils autour.

Personnellement, je ne connais certainement pas assez Java pour en parler d'autorite, mais un probleme classique avec la confusion(*) de l'interface (je sais, il y a une notion d'interface en Java, j'utilise le terme dans un sens moins formel) et de l'implementation, c'est la difficulte a separer le travail -- a utiliser une interface non encore implementee, a garantir que l'interface ne change pas sans revue plus contraignante que pour les changements d'implementations, etc.

(*) Confusion et unification designent essentiellement la meme chose, simplement la desirabilite differe.

Citation:

---

Envoyé par HanLee

(et Visual C++ le fait automatiquement, je crois, mais avec un #pragma once au lieu de faire des #define).

---

Et comment on compile ailleurs?

Citation:

---

Envoyé par Jean-Marc.Bourguet

Et comment on compile ailleurs?

---

Justement c'est le problème. Mais peut-être qu'il y a une option pour modifier ça. Comme tu vois je maitrises pas l'outil non plus ;).

Dans mes souvenirs, les wizards de VC6 rajoutaient les #ifndef et le #pragma once.
Pour vi je ne sais, cela risque d'être un peu pénible
Pour emacs, cela existe
Pour vim, je maintiens un plugin qui fait ça et bien plus encore.

Dans tous les cas, il s'agit d'utiliser un outil de qualité professionnelle et d'apprendre à s'en servir pour ce genre de choses.

De souvenir le #pragma once n'est qu'une optimisation, pas un remplacement pour les #ifndef. Ca permettrait juste d'éviter que le fichier ne soit lu inutilement (à la recherche du #endif correspondant), ou quelque chose dans ce genre.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Si c'est le plus gros reproche que tu as a faire au C++, tu ne le connais pas assez.

---

Oh que oui.

Seulement voilà : il faut avoir été débutant avant d'être expert. Un problème qui ne se pose qu'aux débutants n'est pas pour autant négligeable.
C'est en fait probablement ce qui peut le plus comprommettre l'avenir du C++ : c'est plus facile de former un développeur à Java, donc les entreprises s'orienteront plus facilement vers ce dernier.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Si c'est un facteur important dans ta productivite, c'est que tu ne maitrises pas assez les outils autour..

---

Oui aussi, mais la moindre perte de temps qu'on aurait pu éviter est une perte de temps de trop.

En effet, Code::Blocks par exemple dispose de wizards qui s'en occupent tout seul la plupart du temps. Mais dès que l'on essaye de faire quelque chose d'un peu compliqué, on peut se retrouver à poster un message sur developpez pour demander de l'aide parce que les wizards sont dépassés (et le développeur aussi). Eclipse fait tout, tout seul, y compris les imports, et sans erreurs.

Citation:

---

Envoyé par HanLee

Je pense que ça doit pas être compliqué à faire sous emacs ou vi, avec des macros.

---

Citation:

---

Envoyé par Luc Hermitte

Pour vim, je maintiens un plugin qui fait ça et bien plus encore.

---

Au bout de six mois, je suis censé avoir terminé le développement, pas le commencer :P. Blague à part, les IDE en Java intègrent ça en natif.

Citation:

---

Envoyé par Jean-Marc.Bourguet

J'aimerais bien un système où on n'a réellement à déclarer que l'interface (donc rien de ce qui est privé) de manière séparée de l'implémentation.

---

C'est le cas en Java. De plus les interfaces fonctionnent de façon simple et élégante (par héritage.) Ca permet aussi de créer plusieurs implémentations d'une interface et préciser laquelle utiliser via un fichier xml sans changer le code (utilisé par exemple par le framework Spring avec l'inversion de contrôle).

Mais ça fait beaucoup de texte au sujet de l'absence d'une vraie gestion de modules, je propose d'arrêter là. J'ai simplement évoqué ma dernière difficulté en date, je n'avais pas l'intention de faire la publicité de Java qui a ses propres inconvénients.

Citation:

---

Envoyé par BugFactory

C'est le cas en Java. De plus les interfaces fonctionnent de façon simple et élégante (par héritage.)

---

C'est une façon de définir des interfaces, ce n'est pas la seule (par exemple, regarder pimpl), et elle n'est pas sans inconvénients. En particulier elle impose un coût d'héritage (et de passage par pointeurs) qui peut ne pas être souhaitable dans tous les cas.

Dans un monde idéal, la partie privée d'une classe ne devrait pas faire partie de l'interface de cette classe, et le .h constituerait l'interface publique uniquement.

Pour les modules, le papier se trouve sur http://www.open-std.org/jtc1/sc22/wg...2006/n1964.pdf mais comme l'a dit Jean-Marc, il ne sera a priori pas accepté dans le standard, pour des raisons de temps, principalement.

Bonsoir,

Décidément, le blog d'Herb Sutter est riche en infos sur le futur.
Dernièrement on a eu droit à des liens vers des videos d'exposés "google talk". On y trouve une présentation des nouveautés du C++0x, un exposé sur la "concurrence", un sur les list-initialiser, un sur les concepts, et un sur le multi-threading. (chaque présentation dure environ une heure)

C'est par là: http://herbsutter.spaces.live.com/bl...51BB!239.entry

A propos de l'avenir de C++ et de la pertinence de ce langage pour développer des projets, les points de vue de Benoît Schillings et Matthias Ettrich sont intéressants je pense:
http://qt.developpez.tv/2006-devdays/#benoit-schillings

Dommage qu'actuellement la programmation générique ne soit pas assez connue.
J'espère qu'avec l'arrivée des concepts, entre autres, elle sera plus utilisé. Beaucoup (trop) de gens s'arrêtent à l'écriture, qui peut paraître compliquée, des templates.

J'ai vu aussi qu'au comité on parlait également de quelque chose pouvant faciliter l'utilisation du RAII dans C++0x. Quelqu'un aurait un lien ou un commentaire sur le sujet ?

Au fait, vous avez essayé ConceptGCC ? Votre opinion sur ce compilateur ?

Bah c'est GCC 4.3 + des patchs pour les concepts.

Oui. Je voulais plutôt demander l'avis quand à l'utilisation des concepts avec ce dernier...

En regardant les nouveautés de la nouvelle norme je vois une réutilisation du mot clé "auto". Très bien il est quasiment pas utilisé.
Mais je vois aussi l'introduction d'un nouveau mot clé : "where"...

Et là une question surgit que vont devenir les programmes qui utilisaient ce "where" comme variable ?
Je sens qu'on va être obliger de # definer tout ça pour que ça reste compilable :lol: ? Non ?

Je pense qu'avec un IDE "normal", il suffit de faire un Rechercher/Remplacer : "where" -> "where_1" par exemple. Cette contrainte est vraiment négligeable par rapport à ce que va faire apporter au programmeur ce nouveau mot clé. D'ailleurs il me semble que maintenant c'est remplacé par requires<>. Mais je ne suis pas sur.

C'est peut etre un contextual keyword, comme en C++/CLI ou ref n'est pas un keyword, sauf s'il est suivit de class par exemple "ref class", ...

Il n'y a pas de mot-clé sensible au contexte en C++ ou C++0x.
Il me semble que le mot-clé n'est cependant pas 'where' mais 'requires'.

Oui oui, cf mon message du dessus. Ils l'ont remplacé depuis quelques temps. Dans un certain nombre de pdf, on lit requires mais plus where. Ca faisait trop SQL? :aie: