Discussion :

[seeme]

Bonjour à tous et merci de vos interventions

A plusieurs reprises, le terme "officiel" a été utilisé. J'ai un peu de mal à comprendre l'idée. Ok, vous voulez dire par là qu'il y a un comité qui décide de ce qu'il y aura dans le C++ et un autre comité pour ce qu'il y aura dans Qt (idem avec les autres "gros" frameworks : Boost, WPF, .net,wxWidget, etc.)

Mais du mal à comprendre pourquoi ça serait un défaut ? Pensez vous que la qualité des ces frameworks est moins bonne que ceux qui sont intégrés directement dans un langage ?

Je en sais pas si c'est pertinent pour C++. Il y a le langage et des lib, point. Les libs sont ce qu'elles sont (bonnes, mauvaises, efficaces, bugguées, fiables...).

Je pense que plus généralement, si quelque chose est intégré/packagé directement avec le langage, plus de gens sont susceptibles de l'utiliser (après tout, tu l'as sur ta machine avec ton compilo et tout ce qu'il te faut, logiquement tu vas l'essayer en premier pour savoir si ça te convient). Donc plus d'utilisateurs, donc plus de remontés donc potentiellement plus stable si le feedback des devs est bon.

[Drannor]

Bonjour à tous et merci de vos interventions

A plusieurs reprises, le terme "officiel" a été utilisé. J'ai un peu de mal à comprendre l'idée. Ok, vous voulez dire par là qu'il y a un comité qui décide de ce qu'il y aura dans le C++ et un autre comité pour ce qu'il y aura dans Qt (idem avec les autres "gros" frameworks : Boost, WPF, .net,wxWidget, etc.)

Mais du mal à comprendre pourquoi ça serait un défaut ? Pensez vous que la qualité des ces frameworks est moins bonne que ceux qui sont intégrés directement dans un langage ?

C'est exactement ça.
Quand on pense à JAVA on pense à l'API Java et tout ce qu'elle propose.
C# rime avec .Net
C++ avec STL mais pour tout ce qui est plus haut niveau c'est ce qu'on souhaite.

L’inconvénient c'est que les enseignants que j'ai eu s'arrêtent au package de base : Langage C++ + STL et c'est tout. Du coup, en sortant du cours, on se dit que le C++ pour faire quelque chose de haut niveau ça semble bien plus compliqué qu'en Java ou C# surtout que parfois l'installation de bibliothèque et le link ne sont pas trivial.

[Luc Hermitte]

a- C'est exactement ça.
Quand on pense à JAVA on pense à l'API Java et tout ce qu'elle propose.
C++ avec STL mais pour tout ce qui est plus haut niveau c'est ce qu'on souhaite.

b- L’inconvénient c'est que les enseignants que j'ai eu s'arrêtent au package de base : Langage C++ + STL et c'est tout. Du coup, en sortant du cours, on se dit que le C++ pour faire quelque chose de haut niveau ça semble bien plus compliqué qu'en Java ou C# surtout que parfois l'installation de bibliothèque et le link n'est pas trivial.

a- On pense aussi à SWT / eclipse RCP, et à apache -- et à une pléthore de cots trouvables grâce à google.

b- Et encore, c'est quand ils daignent exposer les étudiants au sous-ensemble STL+string de la SL. (la critique première relative à l'enseignement)

[seeme]

C'est exactement ça.
Quand on pense à JAVA on pense à l'API Java et tout ce qu'elle propose.
C# rime avec .Net
C++ avec STL mais pour tout ce qui est plus haut niveau c'est ce qu'on souhaite.

L’inconvénient c'est que les enseignants que j'ai eu s'arrêtent au package de base : Langage C++ + STL et c'est tout. Du coup, en sortant du cours, on se dit que le C++ pour faire quelque chose de haut niveau ça semble bien plus compliqué qu'en Java ou C# surtout que parfois l'installation de bibliothèque et le link ne sont pas trivial.

Je ne suis pas trop d'accord. Pour moi, que ces packages haut niveau ne soient pas intégrés est une force du langage. C'est à toi de regarder ce qui existe, de tester, de te renseigner et de choisir ce qui correspond au mieux à ton besoin.

Il n'y a pas beaucoup d’intérêt à apprendre à se servir de Qt si au final ta cible ne permet pas de le faire tourner. Par contre connaitre les principes MVC et autre permettront d'évaluer correctement les autres libs.

Le choix me parait moins évident avec par exemple Java (mais je ne connais pas trop son utilisation du point de vue pro, à vous de me dire si je me trompe). Je pense que beaucoup de gens vont juste partir avec ce qui est fourni de base sans se demander s'il n'existe pas des lib qui répondraient mieux à leur besoin.

Tout dépend du degré d'intégration/somme de travail/réponse précise au problème que tu cherches.

[seeme]

Juste pour réagier aux différents messages, j'ai vu les critiques :
- pas de framework haut niveau
- documentation peu fournie ou peu accessible
- problèmes de portabilité
- syntaxe trop complexe par rapport a Java ou C#
- pas d'IDE comparable à Eclipse avec autocomplétion et code-refactoring
etc....

Je me demandais, si vous étiez tous au courant qu'il existe un super Framework C++, nommé Qt (prononcer kioute, par pitié, pas kiouti ou kuté), qui est accompagné de son IDE dédié, QtCreator, qui possède :
- un interface sympa et moderne
- un moteur d'autocomplétion puissant, associé à la documentation dynamique en overlay
- d'une doc du langage mais aussi des outils, très bien faite (pour moi la meilleure doc d'API que j'ai pu voir à ce jour)
- un éditeur d'interface graphique (comme le fait VB.net par exemple)
- intégration de pleni d'outils : git, svn, gdb, valgrind, ...
- dans le même SDk, un outil de gestion des traductions (QtLinguist)

De son coté, le langage Qt (je l'appelle langage car il ajoute de paradigmes et des mots clés inexistants en C++ standard, comme les foreach, les signal, les slots, rapprochant énormement de Java) apporte un API claire, très bien structurée et hyper complete (XML, SQL, Http, FTp, socks, GUI, FS, scripts etc)

De plus, dernierement le projet a été doté d'un langage totalement nouveau, basé sur les technologies qui ont fait le succés de Qt (les meta objets, les signals/slots, etc) et les rend accessible depuis un langage déclaratif très dynamique, adjoint au Javascript, j'ai nommé QML.

A noter aussi que Qt passe très bientôt en version 5.0, avec des performances et une portabilité très accrue, ainsi que des centaines de nouvelles classes/fonctions.

Certaines personne devraient doc sortir du terrain C++ STD ou VSC++ avant de comparer le développement en C et celui en C++ qui n'ont plus grand chose a voir aujourd'hui, et avec Qt, C++ possède un framework de très grande qualité qui n'a rien a envie à Java ou CC# (bien au contraire selon moi, les garbage collector et autre types dynamiques ont des abbération inventées pour pouvoir développer sans réfléchir, ce qui n'est franchement pas une bonne chose)

A bon entendeur !

Personnellement, je fais tout pour éviter de commencer à linker avec des framework de cette taille là (boost idem). Je ne dis pas qu'il faut tout refaire à chaque fois, mais en général, soit on a pas besoin de toutes les fonctionnalités proposées, soit on a des besoin plus spécifiques qui font que l'on va perdre du temps.. (et une troisième catégorie qui a effectivement besoin de ce genre de framework).

Qt creator est pas mal quoi qu'encore un peu jeune. J'ai essayé eclipse, qui perd carrément son intérêt avec CDT (complétion douteuse, il est vite perdu) et anjouta qui ne m'a pas convaincu. J'ai découvert récemment le combo visual /Visual assist avec la chance d'être avec des gens qui les connaissent sur le bout des doigts, et c'est très agréable.

Et moi je dis cul té

Pour revenir au problème de l'enseignement, beaucoup de prof n'enseignent qu'une approche du langage, souvent après une intro à java. Beaucoup d'étudiant prennent alors la décision qu'il ne travailleront pas avec C++.

Je pense que cet abandon de la part des étudiant contribue aussi à empêcher les profs de créer des programmes fouillés.

D'après mon expérience, en début de cursus, on nous fait un aperçu de divers langages venant de plein d'horizons différents (j'ai fait de l'asm, du java, du php, du c, du cpp, du python, du prolog... plein de langages pour la plupart juste survolés). Ensuite on se spécialise dans un domaine (web, embarqué, client lourd, temps réel..) où on va plus essayer de comprendre les techniques et les principes plutôt que les subtilités du langage.

Des langages comme le cpp sont exigeants, et c'est à l'étudiant de faire l'effort et de s'investir dedans. A quoi bon forcer les étudiants avec un programme aussi bon soit-il si 80% d'entre eux s'en foutent royalement et ne bosseront jamais avec?

Et encore une fois, le langage n'est qu'un outil. Tout le monde peut apprendre à coder. Ce qui va faire la différence c'est l'expérience, l'algorithmie, l'architecture, et les connaissances (maths, physique, biologie... selon le domaine), pas le langage (me sortez pas le coup de l'OS en php svp.. )

[Freem]

De son coté, le langage Qt (je l'appelle langage car il ajoute de paradigmes et des mots clés inexistants en C++ standard, comme les foreach, les signal, les slots, rapprochant énormement de Java) apporte un API claire, très bien structurée et hyper complete (XML, SQL, Http, FTp, socks, GUI, FS, scripts etc)

Je l'appelle aussi un langage. Et je ne l'apprécie pas vraiment, donc le "super" et tous les compliments que tu lui donnes je ne m'y associe pas.
Je n'apprécie pas vraiment les lib qui modifient la chaîne de compilation, et Qt ajoute son outil la ou d'autres ont juste développé des mécanismes à base de template. Bon, c'est une question de goûts après

Quand je lis ça, je suis dégoûté et encore plus énervé comme les cours bidons que j'ai eu en école. Je m'aperçois au fil des mes lectures sur Developpez, et ton commentaire particulièrement, que je passe à côté de à côté de ce langage à cause de cette méconnaissance ! Oui, monsieur, je suis pas content

Je suis ravi que mon post ait servi à quelqu'un, vue sa longueur, j'avais un peu peur qu'il ne soit pas vraiment lu
Si ça peut te rassurer, je suis moi-même assez blasé d'avoir dû apprendre son existence seul. Ca, et celle des template, entres autres.

Pour le reste, je trouve que la STL devrait être enseignée au début de l'enseignement du C++. Et ensuite, que l'on force les gens à recoder certaines parties, puis de leur faire s'échanger les codes sources afin qu'ils s'aperçoivent à quel point les outils standards peuvent être bien foutus, et pourquoi il faut éviter le NIH.

Pour le fait que la SL ne soit pas complètement implémentée par tous les compilateurs, j'ai déjà entendu dire, en effet. Ainsi que certaines fonctionnalités du C++ qui semblent être fréquemment désactivées volontairement afin de réduire la taille du binaire et de booster ses performances, comme la RTTI (Run-Time Type Information, ce qui permet les cast dynamiques. Note pour ceux qui sont en cours et qui n'ont pas encore vu ce que c'est.), manifestement majoritairement dans l'embarqué.
Mais je pense que l'embarqué, même si c'est une utilisation du C++ qui ne mérite pas d'être négligée (aucune utilisation de C++ ne le mérite, amha) n'est pas la cible de la majorité des développeurs. (J'adorerai toucher du doigts l'embarqué, mais je ne pense pas pouvoir le faire de sitôt, à mon grand dam).
Donc, je ne pense pas que l'on devrait prendre en compte ce type de développement dès le début. Je pense qu'on devrai casser cette réputation de langage inutilisable dans un premier temps, et une fois ceci fait, apprendre aux gens à utiliser les bons outils du langage aux bons endroits, ce qui est loin d'être aisé je pense.

Bien sûr, j'ai remarqué aussi qu'a chaque fois qu'on parle de comment enseigner, les gens ne sont jamais d'accord (sûrement parce que personne n'a entièrement raison)

Une dernière chose. Je constate que très souvent les gens s'amusent avec les "using namespace xxx". Je trouve que c'est regrettable, parce que je trouve au final que ça ne contribue pas à rendre la lecture du code aisée. J'identifie plus vite std::vector comme faisant partie de la stl que vector.
D'autant que vector pourrait très bien être utilisé pour représenter un vecteur mathématique!
Ce qui fait que j'utilise rarement cette fonctionnalité, je lui préfère les typedef quand l'ensemble est trop long. Par exemple "std::vector<MaClasse>::iterator" devient souvent "iterMaClasse" dans mes codes. (bon, je sais, si jamais j'utilisais une liste avec MaClasse à côté, j'aurai un petit souci de convention de nommage... faudra que j'y réfléchisse un jour)

[jeanlou]

En ce qui me concerne, ayant débuté dans le domaine en 1976 (!), j'ai difficile à me satisfaire utilisant la version Visual C++ 2009 !
Le problème m'incombe, car j'ai abandonné le plaisir de programmer durant plus de 15 années, cause: obligations professionnelles !

Ce que je déplore le plus, c'est le surplus de bibliothèques obsolètes !
Dans les années '80-'90, j'avais un énorme plaisir à créer 'moi-même' (!), les fonctions spécifiques à mes propres besoins.
Je pouvais écrire un programe de plusieurs milliers de lignes, après compilation, il suffisait d'un petite disquette pour le copier !

Quand est-il aujourd'hui ? Bientôt il faudra un Blu-Ray !

Évidemment, si j'avais pu suivi l'évolution d'année en année, j'aurais un autre optique, mais voilà...c'est dur à reprendre, même ayant des bases professionnelles.

J'en suis à la moitié du livre d' Ivor Horton "Visual C++ 2008" et c'est difficile, mais je n'abandonne d'aucune façon !

Quelqu'un a-t-il connu l'époque des mag de COBB ' Inside Microsoft C ' ?
C'était très convivial et instructif.
PS: Excusez mes fautes d'ortographes éventuelles, je suis néerlandophone !
Jean

[Bousk]

Je pouvais écrire un programe de plusieurs milliers de lignes, après compilation, il suffisait d'un petite disquette pour le copier !

Quand est-il aujourd'hui ? Bientôt il faudra un Blu-Ray !

Aujourd'hui ce sont les assets qui prennent le plus de place et nécessitent autant de stockage.

[Hardwarista]

Oui. Le c++ est difficile, parce qu'il a plusieurs couches - comme les oignons (et les ogres Pixar):

1) Le C de base et la gestion de memoire a l'aide des references, pointeurs, tableaux.
Moche et peu securise, mais ultra-performant et indispensable dans des environnements bas-niveau comme l'embarque.

2) Le C++ oriente objet, c'est a dire
A. le polymorphisme a l'execution (heritage,fontions virtuelles)
- utile mais plein d'ambiguites dans la norme
- en plus ca casse la compatibilite binaire du C
B. l'encapsulation grace a public/prive/protege
- utile mais ambigu aussi. Tous les cas de figure ne sont pas utilises.
=> L'oriente objet est actuellement, a mon avis, sur-represente dans les cours pour debutants. C'est la partie du standard a reecrire a mon avis.

3) La metaprogramation templates - ou polymorphisme a la compilation
- tres utile et en train d'evoluer rapidement.
- mal ficele: oblige d'exposer le code dans les _tpl.h
=> sous-represente dans les cours debutants
Et pour cause ca conflicte pas mal avec l'oriente objet.

La bibliotheque standard est basee sur 1 + 2 + 3.
Je pense qu'elle est indispensable ! L'implementation comme l'utilisation correcte sont a enseigner.

4) Les directives pre-processeur - indispensable pour faire certaines choses
=> sous-represente dans les cours debutants
Il y a une espece de tabou la dessus.

Je crois que le C++ est une evolution ratee du C.
Et j'en veux pour preuve le succes de la librairie Qt,
qui detourne subtilement certains mecanismes pour contourner des limitations.
Boost et d'autres librairies ont contribue a dorer la pilule, et c++11 a comble pas mal d'insuffisances, donc je sais pas trop ce que ca donne(ra) maintenant.

Mais j'ai utilise pendant 2 ans le C++ 2003 tel qu'implemente par MSVC2005 et gcc 3.4.x et j'en ai souffert !

Edit:
Les raisons principales que j'ai donnees:
A. Absence d'enseignement de qualite du C++. On enseigne trop superficiellement 2 + 3 + 4. On ne parle pas assez des patterns.
Mais attention: je ne pense pas qu'on puisse enseigner le C++ sans parler des pointeurs et donc du C (le 1)
Trop de choses ? Il faut commencer tot ! ( Lycee 1ere S ?)
B. Absence de portabilite du C++.
Le build-system est different, les messages d'erreur et warning sont differents, le traitement des template est different, le traitement de thread est different (du moins dans C++2003)
Pour faire du multi-plateformes il faut avoir 2 vies au moins.
C. Trop d'outils et de bibliotheques externes/pas assez dans le langage de base
Trop souvent on doit se faire suer a compiler et utiliser une bibliotheque C, mono-plateforme, ou du fortran, ou du Qt (faux C++) pour pouvoir faire des choses tres simples.

D'ailleurs B et C viennent aggraver le A:
Pour pouvoir enseigner le C++ il faut rester mono-plateforme et avoir un IDE beton, avec plein de bibliotheques externes installees et integrees impecablement au build-system.

[Freem]

A. Absence d'enseignement de qualite du C++. On enseigne trop superficiellement 2 + 3 + 4. On ne parle pas assez des patterns.
Mais attention: je ne pense pas qu'on puisse enseigner le C++ sans parler des pointeurs et donc du C (le 1)
Trop de choses ? Il faut commencer tot ! ( Lycee 1ere S ?)
B. Absence de portabilite du C++.
Le build-system est different, les messages d'erreur et warning sont differents, le traitement des template est different, le traitement de thread est different (du moins dans C++2003)
Pour faire du multi-plateformes il faut avoir 2 vies au moins.
C. Trop d'outils et de bibliotheques externes/pas assez dans le langage de base
Trop souvent on doit se faire suer a compiler et utiliser une bibliotheque C, mono-plateforme, ou du fortran, ou du Qt (faux C++) pour pouvoir faire des choses tres simples.

D'ailleurs B et C viennent aggraver le A:
Pour pouvoir enseigner le C++ il faut rester mono-plateforme et avoir un IDE beton, avec plein de bibliotheques externes installees et integrees impecablement au build-system.

Pour ce qui est de la portabilité du système de build, je ne vois pas trop... tu parles des options du compilateur?
Si c'est le cas, alors je te rejoins, je ne crois pas que la norme impose les options de compilation. En même temps, elle ne pourrait pas imposer grand chose, puisque son rôle est de s'assurer que chaque architecture puisse avoir son implémentation, sans être bridée. Ce qui implique de pouvoir ajouter des options pour utiliser les optimisations particulières de cette architecture.
Tiens, maintenant que j'y pense... Il serait très bien possible de créer un compilateur C++ qui génère du bytecode java. Si ça n'existe pas, c'est sûrement parce que les dev C++ n'apprécient pas nécessairement l'idée des machines virtuelles...
Mais c'est possible. D'ailleurs, C++ l'a fait pour .NET (C++/CLI il me semble).

A priori, tu as utilisé visual 2003 en dernier. Sache qu'avec visual studio, le respect du standard est franchement douteux (je pense que ça s'améliore, mais tout le monde connaît, je pense, l'amour de microsoft pour le respect des standards dans les années 90/début 2000). Par exemple, stdint.h, il ne connaît pas, c'est pourtant enfantin à implémenter (juste une suite de #define bon sang!) et présent dans le standard de 99!
Autre chose, du vécu que j'ai eu avec d'anciennes versions de VS: du code qui compilait sur 2003 ne compilait plus sur 2005. Parce que l'auteur de cette immondice avait utilisé des extensions propriétaires de ms qui ont été retirées ensuite. Génial...

Je fais, personnellement, du multi plateforme sans le moindre problème, je suis encore jeune et n'ai pas dépensé tant de temps que ça à m'y former.
Limite, je pense que j'aurai plus de difficultés à programmer en mono plateforme, parce qu'il me faudrait apprendre toutes les optimisations spécifiques à chaque plate forme. Et je suis pas un grand motivé pour le travail dupliqué... (programmeur en même temps )
En fait, c'est la l'intérêt d'utiliser les choses inclues dans la SL: ces choses sont écrites pour avoir le même résultat final (notez bien: pas le même comportement, le même résultat. Pas forcément avec les même perfs non plus d'ailleurs).
D'ailleurs, je n'utilise ni Qt, ni Fortran (que je ne connais pas... je devrais peut-être y jeter un oeil un jour?) et encore moins de bibliothèques mono plateformes.
En C++ (pas en C donc) il y a:
IHM => wxWidgets (qui ont aussi réinventé la roue, pour certains trucs, comme Qt et avec les mêmes raisons je pense).
Jeux 2D => SFML
Jeux 3D => Ogre3D
Reconnaissance d'images => OpenCV (bien qu'honnêtement la doc du binding C++ est à chier, je préfère du coup utiliser l'API C)
Systèmes de fichiers, threads & co => boost

WxWidgets fonctionne de la même façon que tous les framework d'IHM. SFML est simple comme bonjour à utiliser, Ogre, je sais pas, pas eu l'occasion de tester, et OpenCV ben... faut savoir lire la doc, mais c'est plutôt fréquent ça non?

Pour les template, ils fonctionnent pareil sur tous les compilateurs qui respectent la norme. Par contre, ce qui est sûr, c'est que les messages d'erreur quand on les utilise sont assez prise de tête.
Et naturellement, ça change selon le compilateur, ainsi que les warning. Peut-être qu'effectivement, il serait possible de normaliser les messages d'erreurs et warning, mais je soupçonne que ça n'est pas le cas pour éviter d'avoir à maintenir une panoplie de messages d'erreurs. Mais ça n'a rien a voir avec la portabilité. Du code sans erreur ni warning aura les mêmes messages d'erreurs et warning sur n'importe quel compilo standard. (et pour cause: il n'en aura pas ).

Au niveau des reproches que tu fais au C++, je vais me permettre d'en corriger un.

2) Le C++ oriente objet, c'est a dire
A. le polymorphisme a l'execution (heritage,fontions virtuelles)
- utile mais plein d'ambiguites dans la norme
- en plus ca casse la compatibilite binaire du C

En fait, quand on utilise l'orienté objet, on casse la compatibilité binaire avec n'importe quel autre compilateur ou, voire même théoriquement avec des options de compilations différentes sur le même compilateur.
Ceci, parce que dans un souci d'optimisation ils ont lâché la bride sur l'implémentation. C'est une des forces du C++, mais qui a un revers de médaille.
Cela dis... quand on veut écrire des systèmes de plug-in, on passe par le paradigme du C, vu qu'on est en C++ on peut jongler entre les paradigmes, et c'est la une des plus grosses forces de ce langage.

Pour l'encapsulation et la notion de public/protected/private, tous les langages OO l'ont. Ca n'a rien à voir avec C++.

Et pour clôturer: j'aimerai que tu m'indiques en quoi la méta programmation est en conflit avec l'objet? J'ai envie de dire que c'est comme si on avait un langage pour que le compilateur génère du code lui même a partir d'un modèle. Modèle qui est lui extrêmement réutilisable, ce qui correspond tout à fait à la philosophie objet.

[Hardwarista]

Pour ce qui est de la portabilité du système de build, je ne vois pas trop... tu parles des options du compilateur?
Si c'est le cas, alors je te rejoins, je ne crois pas que la norme impose les options de compilation. En même temps, elle ne pourrait pas imposer grand chose, puisque son rôle est de s'assurer que chaque architecture puisse avoir son implémentation, sans être bridée. Ce qui implique de pouvoir ajouter des options pour utiliser les optimisations particulières de cette architecture.
Tiens, maintenant que j'y pense... Il serait très bien possible de créer un compilateur C++ qui génère du bytecode java. Si ça n'existe pas, c'est sûrement parce que les dev C++ n'apprécient pas nécessairement l'idée des machines virtuelles...
Mais c'est possible. D'ailleurs, C++ l'a fait pour .NET (C++/CLI il me semble).

Je parle surtout du fonctionnement du make: les dependances entre .h et .cpp, entre objets et librairies statiques et librairies dynamiques, l'export de symboles depuis une librairie etc. Ces choses la sont traitees de maniere tres similaire par toutes les plateformes - sans exclure le fait qu'il y a des optimisations specifiques. C'est pour ca que CMake ou scons existent d'ailleurs. Est-ce que la norme en parle ? Je suppose que non parce que les objets et librairies produits ne sont pas censes etre transferables. Mais le savoir-faire du developpeur si ! D'ailleurs si la norme en parlait les cours de C++ en parleraient aussi.

Oui, j'aime bien ton idee d'une machine virtuelle qui re-assemblerait le code machine en fonction de la plateforme. Comme ca tout ce que j'ecris pour la machine virtuelle prend plus de valeur.

A priori, tu as utilisé visual 2003 en dernier. Sache qu'avec visual studio, le respect du standard est franchement douteux (je pense que ça s'améliore, mais tout le monde connaît, je pense, l'amour de microsoft pour le respect des standards dans les années 90/début 2000). Par exemple, stdint.h, il ne connaît pas, c'est pourtant enfantin à implémenter (juste une suite de #define bon sang!) et présent dans le standard de 99!
Autre chose, du vécu que j'ai eu avec d'anciennes versions de VS: du code qui compilait sur 2003 ne compilait plus sur 2005. Parce que l'auteur de cette immondice avait utilisé des extensions propriétaires de ms qui ont été retirées ensuite. Génial...

Je n'ai utilise que VS2005. Je compatis.

Pour les template, ils fonctionnent pareil sur tous les compilateurs qui respectent la norme. Par contre, ce qui est sûr, c'est que les messages d'erreur quand on les utilise sont assez prise de tête.
Et naturellement, ça change selon le compilateur, ainsi que les warning. Peut-être qu'effectivement, il serait possible de normaliser les messages d'erreurs et warning, mais je soupçonne que ça n'est pas le cas pour éviter d'avoir à maintenir une panoplie de messages d'erreurs. Mais ça n'a rien a voir avec la portabilité. Du code sans erreur ni warning aura les mêmes messages d'erreurs et warning sur n'importe quel compilo standard. (et pour cause: il n'en aura pas ).

Mm certes. Mais le fait est que la meme cause d'erreur donne 3 messages differents sur 3 plateformes differentes. Le connexions neuronales perdues a faire le rapprochement moi je dis c'est rageant.

Et puis les templates c'est pas magique: les classes c++ sont instanciees pour chacune des valeurs de parametre de template. Et c'est le meme combat pour les #define. Pour quoi ne pas me montrer dans un fichier temporaire le code effectifvement genere ?! Et le TMP c'est comme du langage interprete, donc ca devrait etre deboguable comme du langage interprete.

Au niveau des reproches que tu fais au C++, je vais me permettre d'en corriger un.

En fait, quand on utilise l'orienté objet, on casse la compatibilité binaire avec n'importe quel autre compilateur ou, voire même théoriquement avec des options de compilations différentes sur le même compilateur.
Ceci, parce que dans un souci d'optimisation ils ont lâché la bride sur l'implémentation. C'est une des forces du C++, mais qui a un revers de médaille.
Cela dis... quand on veut écrire des systèmes de plug-in, on passe par le paradigme du C, vu qu'on est en C++ on peut jongler entre les paradigmes, et c'est la une des plus grosses forces de ce langage.

Je ne sais pas si c'est un probleme insoluble de merger deux versions d'un dll tout en faisant un mapping des symboles C++. Je ne sais pas non plus s'il y a des langages qui le font. En tout cas ca manque. Et je ne vois pas de raison de faire un compromis sur la performance.

Et pour clôturer: j'aimerai que tu m'indiques en quoi la méta programmation est en conflit avec l'objet? J'ai envie de dire que c'est comme si on avait un langage pour que le compilateur génère du code lui même a partir d'un modèle. Modèle qui est lui extrêmement réutilisable, ce qui correspond tout à fait à la philosophie objet.

Voir la premiere partie de cet article
http://www.artima.com/cppsource/type_erasure.html

Puis voir comment Java et C# traitent le probleme.
http://en.wikipedia.org/wiki/Polymor...c_Polymorphism

Le souci avec C++ c'est que les templates n'ont pas etes concus pour s'integrer bien avec le concept d'API oriente object. Combien de fois on n'essaie de templatiser une fonction ou une classe, pour eviter de dupliquer du code, et qu'on se retrouve avec une horreur de chaine d'inter-dependances qui ralonge la compilation et oblige a changer les fonctions publiques virtuelles ?

Le fait qu'il n'est pas possible d'exporter des template est aussi dans la meme ligne.

Aussi, toutes les classes-template de conteneurs de la STL ne sont pas concues pour etre etendues par heritage. Mais dans ce cas ca devrait s'appeler differement ! De dire "les classes on peut les etendre par heritage" puis "ah non pas celles-la" c'est assez tordu je trouve.

[Ekleog]

[...]
Oui, j'aime bien ton idee d'une machine virtuelle qui re-assemblerait le code machine en fonction de la plateforme. Comme ca tout ce que j'ecris pour la machine virtuelle prend plus de valeur.

LLVM est à peu près ça. D'ailleurs, son nom le prouve : Low Level Virtual Machine.
Mais l'avantage du c++ est justement qu'on a le choix de compiler ou interpréter ou JIT-er son code !

[...]
Et puis les templates c'est pas magique: les classes c++ sont instanciees pour chacune des valeurs de parametre de template. Et c'est le meme combat pour les #define. Pour quoi ne pas me montrer dans un fichier temporaire le code effectifvement genere ?! Et le TMP c'est comme du langage interprete, donc ca devrait etre deboguable comme du langage interprete.

g++ -save-temps

Le souci avec C++ c'est que les templates n'ont pas etes concus pour s'integrer bien avec le concept d'API oriente object. Combien de fois on n'essaie de templatiser une fonction ou une classe, pour eviter de dupliquer du code, et qu'on se retrouve avec une horreur de chaine d'inter-dependances qui ralonge la compilation et oblige a changer les fonctions publiques virtuelles ?

0 ?
Si la classe est bien pensée à l'origine, elle n'aura pas de difficulté à être "templatisée", si elle doit l'être.

Le fait qu'il n'est pas possible d'exporter des template est aussi dans la meme ligne.

Un exemple d'utilité de l'export template ?
L'export template est plus ou moins équivalent à placer le code c++ des templates dans le .o, donc ça avance à quoi ?

Aussi, toutes les classes-template de conteneurs de la STL ne sont pas concues pour etre etendues par heritage. Mais dans ce cas ca devrait s'appeler differement ! De dire "les classes on peut les etendre par heritage" puis "ah non pas celles-la" c'est assez tordu je trouve.

Tu devrais te renseigner sur les notions de sémantique d'entité / de valeur.
Rapidement :
Sémantique d'entité -> non copiable, héritables publiquement
Sémantique de valeur -> copiable, non héritables publiquement, potentiellement héritage privé

Les classes de la SL sont conçues pour être à sémantique de valeur, pour la plupart (à part les *stream, si je ne me trompe pas). D'où le fait qu'il faut éviter de les hériter publiquement. L'héritage privé reste toutefois une option, mais la composition reste souvent la meilleur idée.

[koala01]

Aussi, toutes les classes-template de conteneurs de la STL ne sont pas concues pour etre etendues par heritage. Mais dans ce cas ca devrait s'appeler differement ! De dire "les classes on peut les etendre par heritage" puis "ah non pas celles-la" c'est assez tordu je trouve.

Non, il est tout à fait normal qu'une classe "conteneur" ne soit pas héritable, selon le principe même évoqué par LSP

Après tout: tu spécialise ton conteneur pour qu'il s'adapte à un type de donnée ou à un autre (sans qu'il n'y ait de rapport entre conteneur<int> et conteneur<string> ), mais tu n'hérite pas d'un conteneur : une liste triée n'a, en vertu de LSP absolument pas à hériter d'une liste (non triée), parce que les pré / post conditions / invariants sont différents (tout comme carré n'a absolument pas à hériter de rectangle malgré le fait que, du point de vue des mathématiques, un carré n'est jamais qu'une "rectangle particulier" )

J'ai presque envie de dire que ta réaction met, encore une fois, en évidence une lacune au niveau de la conception elle-même : le fait qu'une classe puisse avoir une interface identique à une autre n'est jamais qu'un indice (parmis d'autres!!! ) du fait qu'il est peut etre possible (mais loin d'être systématique !!!) d'envisager une relation d'héritage ou l'intégration dans une hiérarchie commune, mais, et c'est là que pose le problème, l'héritage implique qu'il doit etre sémantiquement cohérent d'estimer qu'un objet de la classe fille est bel et bien un objet de la classe parent, et que les pré / post conditions / invariants sont respectés dans les différents sens

Finalement, je ne suis pas loin de penser que ce qui manque peut etre dans l'enseignement (pas seulement de C++ ) , c'est une approche de la programmation par contrat, durant laquelle on insisterait sur le corrollaire aux pré / post conditions / invariants : le principe de substitution de liskov

[Flob90]

Pour ce qui concerne la méta-prog pré-processeur et template, le sujet étant : "Le C++, un langage orienté débutant". Je pense que ca ne fait pas partie des choses qui devraient être enseigné. Il y a déjà suffisament à apprendre avec :
-> Impérative
-> Objet (je rajouterais bien une approche contrat avec)
-> Générique

@Ekleog: Non, pas obligé d'utilisé le pré-processeur pour simuler des variadic. L'utilisation du pré-processeur dans la simulation des variadics n'est qu'"user-friendly", c'est pas fondamentale.

@oodini:
1/ Si tu veux discuter des compilateurs, alors il faut te tourner vers les ouvrages de référence dans le genre : Dragon Book. Si tu veux plus précis sur certains compilateurs, alors ce sont vers des ouvrages dédié à eux qu'il faut aller (là j'en connais pas).

Les livres de Sutter/Meyers font livre de recette ? C'est normal, c'est l'objectif voulu : donner un ensemble de conseils pour programmer en C++. Je pense que les livres de BS ne font pas cet effet, et les livres sur des sujets plus spécifique n'ont pas cet effet non plus.

2/ Pour boost :
-> La grande majorité est header-only, plus simple à installer c'est dur
-> Sur tout les systèmes Unix, il se trouve souvent dans les dépots officiels et est accessible via le gestionnaire de paquet
-> Sur Windows, si tu utilises les outils de Microsoft, alors il existe un installateur Windows classique qui fait l'installation
-> Dans les autres cas, quand on utilise des outils venant du monde Unix et adaptés ensuite pour Windows, ca ne m'étonne pas que ce soit (un peu) moins simple que dans les autres cas

@Hardwarista: Je connais pas cet article (par contre le type-erasure je connais), je vais le regarder pour voir.

[Flob90]

2) Le C++ oriente objet, c'est a dire
A. le polymorphisme a l'execution (heritage,fontions virtuelles)
- utile mais plein d'ambiguites dans la norme
[...]
B. l'encapsulation grace a public/prive/protege
- utile mais ambigu aussi. Tous les cas de figure ne sont pas utilises.

Tu as des exemples d'ambiguités ? Je ne vais pas mettre ma main à couper qu'il n'y en a pas, mais de la à dire "plein"

De même pour les "cas de figure non utiles", tu penses à quoi en particulier ? Je suis bien d'accord que certaines choses n'arrive pas si on se borne à l'orienté objet, mais ils peuvent servirent dans d'autre situation.

=> L'oriente objet est actuellement, a mon avis, sur-represente dans les cours pour debutants. C'est la partie du standard a reecrire a mon avis.

A défaut d'être sur-représenté, je pense surtout qu'il est mal enseigné et que les autres paradigmes sont sous-représenté.

3) La metaprogramation templates - ou polymorphisme a la compilation
- tres utile et en train d'evoluer rapidement.
- mal ficele: oblige d'exposer le code dans les _tpl.h
=> sous-represente dans les cours debutants
Et pour cause ca conflicte pas mal avec l'oriente objet.

Je ne vois pas ce qui "conflicte" avec l'OO, ce sont des systèmes orthogonaux, ca amène bien le besoin de certaines syntaxes, mais pas de réel conflit, AMA.

Pour l'obligation d'exposition, la séparation interface/implémentation était possible dans le précédent standard (export), sauf qu'aucun compilateur (ou presque : EDG) ne l'implémentait. Cette feature a été retiré pour deux raisons (je détaille pas, cf raport du comité pour les détails) :
-> Complexe à mettre en oeuvre (plusieurs années de développement)
-> Peu demandé par les utilisateurs
(Il y a aussi des problèmes techniques).

4) Les directives pre-processeur - indispensable pour faire certaines choses
=> sous-represente dans les cours debutants
Il y a une espece de tabou la dessus.

C'est pas qu'il y a un tabou, c'est surtout que ce qui peut n'être fait que par le pré-processeur est négligeable devant le reste, donc, AMA, ca ne doit être enseigné qu'à la fin. Sinon c'est la porte ouverte à voir du code pré-processeur là où de la TMP suiffirait.

[Ekleog]

C'est pas qu'il y a un tabou, c'est surtout que ce qui peut n'être fait que par le pré-processeur est négligeable devant le reste, donc, AMA, ca ne doit être enseigné qu'à la fin. Sinon c'est la porte ouverte à voir du code pré-processeur là où de la TMP suiffirait.

Avant les variadic templates, c'était quand même un passage quasiment obligé. Non ?

[oodini]

1. La qualité de l'enseignement du C++

J'ai appris en autodidacte. Je ne saurais donc dire...
D'un point de vue bouquins, ce qui manque, en revanche, c'est tout ce qui concerne les performances, les optimisations effectuées par les compilateurs, etc. Ainsi qu'un livre qui décrit exhaustivement le C++, avec toutes les chausse-trappes (il serait sans doute constitué de plusieurs volumes), plutôt qu'une collection de livres de recettes (Meyers, Sutter...).

2. La gestion bas niveau de la mémoire
C'est une possibilité, rarement une obligation.

3. L'absence de mécanisme de protection (garbage collector)
Quand c'est expliqué clairement (dans un cours ou un bouquin), c'est au final plus clair, je pense. Mais bon, c'est vrai que lorsque on est obligé d'utiliser des classes RAII templatisées, au début, ça ne facilite pas l'apprentissage...

4. Une syntaxe trop complexe
Elle devient complexe quand on atteint un certain niveau, et à ce moment là, elle ne devient plus complexe. Sauf quand on est dans de la généricité de bon niveau. Même après quelques années, il existe encore quelques frictions mentales.

5. Pas assez de fonctionnalités dans le langage de base (IHM)
Clairement. Notamment sur les strings. Heureusement que C++11 apporte les threads.

6. Trop d'outils ou de bibliothèques externes
C'est pas tant leur nombre qui pose problème, mais plutôt quand aucune se détache du lot, que leur doc est merdique, ou que leur intégration n'est pas simple (mettre en place Boost pour un débutant, ce n'est pas une sinécure).

7. Des abstractions haut niveau trop complexes (template)
Elles sont complexes parce qu'elles sont de haut niveau. Aucun autre langage ne propose une telle expressivité. De toute façon, on ne se détermine pas sur le choix d'un langage en lisant Alexandrescu...

8. L'évolution trop lente du langage et le retard qu'il a pris
Point de vue langage, il est plutôt en avance (même si sur la dérivation de classe, il y a des choses à faire). C'est du côté des bibliothèques que ça traine des pieds...

9. Le manque de portabilité du C++
C'est vrai que le recours obligatoire à Boost.FileSystem et, jusqu'à il y a peu, à Boost.Thread, rendait les choses pénibles. Surtout que l'installation de Boost n'est pas des plus aisées pour le débutant. Sans compter les systèmes de build...

10. Un système de compilation beaucoup trop complexe
C'est à mon sens le plus gros point noir. Ce n'est pas clair, et peu documenté.
Et quant on doit faire du multi-plate-formes, rien en vas plus.
Par ailleurs, je ne pense pas que les enseignements poussent assez sur le sujet : souvent, on a des trucs tout cuits, mais des explications détaillées sur les problèmes posés par les conflits de variables entre .lib/.dll, par exemple, ce n'est pas si facile à trouver.

11. Les messages d'erreurs incompréhensibles
On s'y fait... Bien plus facile chez Microsoft, notamment avec les codes d'erreur.
Dès qu'on utilise les templates, c'est assez l'horreur, il faut bien l'avouer.

12. Le manque de ressources pour l'apprentissage
Il y en a pléthore. Mais certains sujets sont en revanche peu documentés. Les flux, l'environnement de compilation/édition de lien, les IDE, le déboguage...

[Freem]

Avant les variadic templates, c'était quand même un passage quasiment obligé. Non ?

Je ne trouve pas.
Parce que la ou je vois du préprocesseur, c'est pour:
_ activer/désactiver des options dans un logiciel. Chose qui pourrait être faite via un système de plugin, moyennant une architecture étudiée dans ce sens.
_ garantir la compatibilité entre divers OS. En fait, souvent garantir la compatibilité avec windows. Les #IFDEF que je vois sous souvent suivis de WIN32...

L'utilisation des macros, quand à elle, est plutôt anecdotique. Par exemple, elles sont utilisées par wxWidgets pour gérer les évènements. Sauf qu'ils ont enfin laissé tomber ce système pour un basé sur des callbacks.
Je les utilise dans un projet professionnel également, pour écrire plus vite des classes de wrapper, qui n'ont strictement aucune logique dedans. Et d'ailleurs, elles sont trop limitées pour ce que je voudrais en faire. (J'aurai bien utilisé les variadic template, malheureusement, je dois utiliser VS2008...)

Ah, si, une autre utilisation des macros, non remplaçable par les variadic templates: pouvoir écrire du code de journalisation, surtout pour le mode debug, grâce aux macros __LINE et __FILE. Très utile ça pour le débogage. Mais pas pour le code métier je pense.

Autre chose qui nécessite les directives de préproc, les header guard. Ajouter le fameux #ifndef TRUC_H #define TRUC_H #endif dans les header n'est cependant qu'un idiome auquel on ne fait plus attention au bout de 2 mois. (Je me demande d'ailleurs pourquoi les header ne sont pas traités comme ça par défaut mais bon...)

[Bousk]

Autre chose qui nécessite les directives de préproc, les header guard. Ajouter le fameux #ifndef TRUC_H #define TRUC_H #endif dans les header n'est cependant qu'un idiome auquel on ne fait plus attention au bout de 2 mois. (Je me demande d'ailleurs pourquoi les header ne sont pas traités comme ça par défaut mais bon...)

Parce qu'on peut vouloir inclure plusieurs fois le même header !
Et si c'était géré par défaut de cette manière, ça deviendrait impossible.

[Ekleog]

Je ne trouve pas.
Parce que la ou je vois du préprocesseur, c'est pour:
_ activer/désactiver des options dans un logiciel. Chose qui pourrait être faite via un système de plugin, moyennant une architecture étudiée dans ce sens.

Sauf que parfois l'overhead peut être extrèmement couteux. (enfin, ça dépend si on parle de plugin à la compilation ou à l'exécution, mais j'ai plus tendance à appeler modules les plugins à la compilation)

_ garantir la compatibilité entre divers OS. En fait, souvent garantir la compatibilité avec windows. Les #IFDEF que je vois sous souvent suivis de WIN32...

Toujours est-il que la compatibilité est toujours importante, quelle que soit l'opinion qu'on se fait du système ciblé et de ses API.

L'utilisation des macros, quand à elle, est plutôt anecdotique. Par exemple, elles sont utilisées par wxWidgets pour gérer les évènements. Sauf qu'ils ont enfin laissé tomber ce système pour un basé sur des callbacks.
Je les utilise dans un projet professionnel également, pour écrire plus vite des classes de wrapper, qui n'ont strictement aucune logique dedans. Et d'ailleurs, elles sont trop limitées pour ce que je voudrais en faire. (J'aurai bien utilisé les variadic template, malheureusement, je dois utiliser VS2008...)

Quand je disais avant les variadic templates, je pensais entre autres a fait de proposer des fonctions variadic templates.
Exemple : boost.function pré-variadic templates.
Et, comme tu le dis si bien, les macros sont toujours nécessaires pour faire une partie le boulot sur un compilo sans les variadics, et ces compilateurs existent malheureusement encore ...
Alors, oui, il y a boost & co. pour nous cacher les macros, mais c'est un des trois langages du c++ (en excluant l'asm, hein -- je ne suis pas sûr que je n'en oublie pas d'autre), chacun influant sur son moment de la compilation / de l'exécution.

Ah, si, une autre utilisation des macros, non remplaçable par les variadic templates: pouvoir écrire du code de journalisation, surtout pour le mode debug, grâce aux macros __LINE et __FILE. Très utile ça pour le débogage. Mais pas pour le code métier je pense.

M'est avis que le code métier a quand même des macros avec, désactivés avec l'activation de NDEBUG.

Autre chose qui nécessite les directives de préproc, les header guard. Ajouter le fameux #ifndef TRUC_H #define TRUC_H #endif dans les header n'est cependant qu'un idiome auquel on ne fait plus attention au bout de 2 mois. (Je me demande d'ailleurs pourquoi les header ne sont pas traités comme ça par défaut mais bon...)

Parce que sinon beaucoup d'autres idiomes disparaitraient ?
Exemple, boost.pp.iterate_file (ou quelque chose du genre).