L'avenir du C++

**Matthieu Brucher** · 06/04/2006, 18h50

SDL, c'est plutôt du C que du C++.

**outs** · 06/04/2006, 18h58

Envoyé par Miles

SDL, c'est plutôt du C que du C++.

Exact il fallait lire STL. merci

**Jean-Marc.Bourguet** · 06/04/2006, 20h12

(J'aurais juré avoir déjà répondu...)

Envoyé par outs

Envoyé par Jean-Marc.Bourguet

Ca me fait peur... je n'ai qu'un marteau, donc il n'y a que des clous... :-)

Ce n'est pas justifié. Les bibliothèques C++ (du style SDL, qt, par contre pas les bibliothque provenant du C) ont la même forme que celle d'eiffel. Tu pense vraiment qu'ils procedent différement que ce dont tu a l'habitude?

Il y a au moins une habitude que j'ai qu'une approche "intégriste" n'a pas: c'est d'utiliser le concept adapté au problème plutôt que d'adapter le problème aux concepts que j'accepte d'utiliser. Il me semble que la fonction libre est le concept adapté pour des fonctions comme cosinus (en tout cas, on ne m'a pas encore fourni le moindre argument du pourquoi ce ne le serait pas). Devoir en faire un membre d'une classe, c'est adapter le problème aux concepts.

Envoyé par Jean-Marc.Bourguet

Pour la compilation native, je ne vois pas tellement en quoi la purete intervient. D'ailleurs j'ai du mal a voir exactement ce qu'est la purete

Oui c'est pas un très bon terme, je voulais juste dire que c'est plus simple de faire un compilo performant quand le langage ne part pas dans tous les sens (impératif + modules + objet + fonctionnel genre Ada ou Ocaml).

Tu peux enlever performant. Il est plus simple de faire un compilo pour un langage simple qu'un langage compliqué. Je l'admet sans problème. Mais je préfère que la complication soit dans le langage et le compilateur plutôt que dans mes programmes. Je préfère un langage qui me permette de m'exprimer clairement plutôt que de passer par des détours.

**outs** · 06/04/2006, 20h52

Envoyé par Jean-Marc.Bourguet

(J'aurais juré avoir déjà répondu...)

Désolé de te décevoir mais encore une question et je m'en vais :
Donc pas d'espoir de voir un changement dans le systeme des référence de C++ dans la prochaine version ?
(c'était ma question principale)

**Jean-Marc.Bourguet** · 06/04/2006, 21h12

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

**JolyLoic** · 06/04/2006, 21h20

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 ?

**Jean-Marc.Bourguet** · 06/04/2006, 21h36

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.

**outs** · 06/04/2006, 21h39

Envoyé par JolyLoic

Je n'ai pas connaissance de changement dans ce domaine

Merci de la réponse

**Aurelien.Regat-Barrel** · 06/04/2006, 22h59

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

Code :

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

A & a = new B();

**loufoque** · 06/04/2006, 23h38

Envoyé par Aurelien.Regat-Barrel

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

Code :

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

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.

**Jean-Marc.Bourguet** · 07/04/2006, 08h48

Envoyé par Aurelien.Regat-Barrel

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

Code :

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

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 :

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

A& a = *newB();

ne resouds pas?

**Xadeck** · 27/06/2006, 11h29

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 :

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

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 :

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

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

**Luc Hermitte** · 27/06/2006, 23h56

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.

**Xadeck** · 28/06/2006, 09h16

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.

**Matthieu Brucher** · 28/06/2006, 12h55

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.

**BugFactory** · 21/03/2007, 19h57

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

**Jean-Marc.Bourguet** · 21/03/2007, 20h44

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.

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.

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

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

**BugFactory** · 22/03/2007, 11h38

Tous ces arguments sont valables.

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

**HanLee** · 22/03/2007, 13h18

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.