Discussion :

[Jean-Marc.Bourguet]

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]

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]

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]

Je n'ai pas connaissance de changement dans ce domaine

Merci de la réponse

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

[loufoque]

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]

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]

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]

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]

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]

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.

[Syrmonsieur]

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 :

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

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

ne marche pas alors que fonctionne :

Code :

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

 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 :

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

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 :

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

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.

[Luc Hermitte]

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

[JolyLoic]

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.

[Luc Hermitte]

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

[zais_ethael]

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?

[Matthieu Brucher]

Comme c'est facultatif, c'est bien.

[loufoque]

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

[BugFactory]

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]

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.