Je n'ai pas compris quels changements tu voudrais...Envoyé par outs
Je n'ai pas compris quels changements tu voudrais...Envoyé par outs
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 ?
Il y a bien les "Rvalue References", mais je ne sais pas si ça correspond à ce qu'il veut.Envoyé par JolyLoic
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 ?Envoyé par Aurelien.Regat-Barrel
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.
Quel est le probleme que ca resoudrait (on parlait aussi de complexite inutile, ajouter quelque chose augmente la complexite) queEnvoyé par Aurelien.Regat-Barrel
ne resouds pas?
Code : Sélectionner tout - Visualiser dans une fenêtre à part A& a = *newB();
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 :
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 #ifdef NEVER_DEFINED try (to [fontify this code) { ah!ah! ;-) } #endif
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++.
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 ?!?! }
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 :
ne marche pas alors que fonctionne :
Code : Sélectionner tout - Visualiser dans une fenêtre à part string str = "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 string str = string("salut") + " tout le monde";
- 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 type& ref = object1; ref = value; // fixe la valeur d'object1 ref := object2; // maintenant ref reference object2
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.
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
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à.
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.Envoyé par BugFactory
Ce n'est pas si contraignant que cela.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.
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.- 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...
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.- Difficultés comme celles que j'ai évoquées ici:
http://www.developpez.net/forums/sho...d.php?t=300238
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager