le but n'est pas d'avoir des outils moins puissant techniquement loin de la , mais le but est d'avoir des outils qui font abstraction le plus possible a toute la complexité technique.
Version imprimable
Effectivement on aura toujours besoin pour certains domaines mais ma crainte et que ça sera de moins en moins.
toute technologie passe par trois phases: évolution, stagnation et puis récession a cause de migration vers d'autres technos.
actuellement C++ est en stagnation et le nombre de nouveaux projets développé en C++ décroit chaque année.
et forcement il y aura toujours de nouveaux projets qui se développent en C++ mais de moins en moins et ça touche surtout les softs de type système,embarqué et jeux.
et puis il y a un autre point en défaveur de c++, il s'agit de la convergence des applications web et desktop et voila le probléme:
imaginant qu'on développe une application desktop avec c++ et que demain on veut la rendre aussi disponible en Web, alors si la conception est bien faite ou les couches sont bien isolées on peut dire que c'est facile, mais le probléme réside dans l'intégration entre langages , entre java et c++ c'est pas le paradis et entre dotnet et c++ il y le C++\cli mais reste spécifique a windows.
le web devient parmi les endroits favoris de plusieurs types d'applications et faire le mélange entre différents langages pour y arriver rend la vie compliqué.
et du moment ou on a moins de projets on aura automatiquement dans le futur moins de ressources puisqu'on privilégie la ou on est sur de trouver un job rapidement.
a mon avis il y a plusieurs facteurs qui commence a limiter le choix de c++, et si la comité de standardisation n'accélère pas les évolutions au niveau langage et librairies standards pour faire plus abstraction aux problèmes techniques récurrents ça peut être trop tard.
moi je suis pour une pétition ou des millions de développeurs C++ donne leur avis sur la lenteur de standardisation et la soumettre a la comité :)
peut être j'ai tort parce que j'ignore complètement toutes les difficultés de standardisation mais ce qui est sur c'est qu'il faut quelque chose avant que ça soit trop tard.
Je pense surtout que les échelles de valeurs ont énormément évolué...
A l'époque, on considérait qu'une application nécessitant quatre disquettes (6Mb et une chique, un peu plus si c'était compressé) d'installation était énorme, alors que, maintenant, on considère comme tout à fait normal qu'une application nécessite plusieurs giga d'espace disque.
A l'époque, on considérait normal de n'avoir que des application "texte" (ou proche de l'être) ou de ne disposer que de 255 couleurs alors que maintenant, on est presque perdu si l'on ne dispose pas d'un "cliquodrome" ou qu'on ne sais pas avoir un rendu correct des images à l'écran...
A l'époque, on ne s'étonnait pas que l'imprimante fasse un bruit de mitrailleuse pendant 45 secondes pour sortir une seule page de texte, alors que, maintenant, on s'offusque dés qu'il faut plus de 6 secondes pour avoir une impression, en couleurs, avec une photo (bien rendue) dans le coin.
Actuellement, il semble "normal" à tout le monde de discuter avec quelqu'un qui se trouve à l'autre bout de la terre, ou de regarder un film sur l'ordinateur, alors que personne n'aurait oser imaginer de le faire dans les années 80 (ou peu s'en faut)
Mais ce qu'il fallait "découvrir" dans les années 80 est, à l'heure actuelle tellement documenté partout que c'est à la portée "du premier imbécile venu"
En un mot, chaque époque a eu ses défis qui sont devenus, par la suite, le B-A-BA de l'époque suivante.
Comme on demande de plus en plus à nos applications, elles deviennent de plus en plus complexes, et de plus en plus gourmandes en ressources (tous types confondus)
On peut dire que c'est parce que le matériel devient de plus en plus performant que l'on ose actuellement envisager de faire des choses que l'on pensait impossibles il y a dix ans à peine.
Mais d'un autre coté, si le matériel n'avait pas évolué comme il l'a fait, il y a bon nombre de défis que nous n'aurions jamais pu relever...
Aucun problème pour le web ! C'est du pur client serveur, donc pas d'interaction inter-langage à la JNI à effectuer, ce sont des techniques utilisées couramment pour RoR, Django, ... Les navigateurs sont dans des langages très différents, et le toolkit le plus utilisé est en C++.
la majorité des applis web ne sont pas fait avec RoR , il y a du java , du php et autres et a un moment donnée il faut les communiquer avec C++ si notre métier est en c++, et la on a besoin du marshaling et intégration entre les langages.
et en parlant de client/serveur et du distribué, j'ai travailler pendant des années dans ce domaine en utilisant plusieurs framework de Corba et aussi DCOM et Com+ et aussi les webservices et sincèrement c++ n'est pas l'idéal pour ça.
on revient au fait que les types de projet qui se développe actuellement a C++ décroit de plus en plus.
et il y a une différence entre :on peut faire tout en C++ et laquelle des technologies est la plus adapté pour un besoin donné ou on prend en compte plusieurs facteurs:
- facilité d'implémentation.
- disponibilité de ressources.
- techno évolutif ou pas
peut être je vois la difficulté d'implémentation en c++ la ou tout est facile parce que j'ai un niveau moyen mais j'ai l'impression que beaucoup ont le même souci.
Tu crois que faire communiquer php et Java, c'est plus simple ?? Il y aura toujours le problème de l'interaction entre les langages, C++ n'est donc pas moins ou plus avantagé dans le tas.
effecivement c'est plus compliqué d'ailleurs , mais je parlais des difficultés qui limite le choix de c++ par rapport a d'autres langages ou on peut tout faire desktop et web comme java et dotnet.
par exemple imaginant que je suis décideur et j'aimerais faire des applications a la fois web et desktop et en commun il y a quelque modules , alors j'aurais tendance a choisir la même techno pour rester homogène.
c'est pas un point faible que c++ ne traite pas le web mais ça limite les nouveaux projets développés avec c++ vu la convergence de plus en plus entre web et desktop.
donc finalement je veux juste dire que le choix de c++ pour les nouveaux projets commence a diminuer et c'est pas bien pour une techno, parce que si cette tendance continue on aura une pénurie de ressources(un developpeur choisit la techno ou il y a plus de boulot) et du coup la techno va entrer dans une récession juste parce que il n y a pas assez de ressources.
Je pense qu'il s'est traduit. Outre les exemples déjà cité, il s'est aussi traduit dans les "performances" au design time des applis. Ce qu'on développe aujourd'hui en quelques clicks et 5 minutes, et de manière robuste, il fallait des mois pour le faire dans les années 80.
Le coût de développement entre dans les critères de qualité d'une appli, et un développeur qui mettrait 20% de temps en plus pour développer une application qui tournerait 2 fois plus vite, je n'en voudrais pas dans beaucoup de domaines d'application.
Tout ça est permi par l'abstraction, qui a un coût, mais que je suis bien content de payer en général.
Si tu présentes les choses comme ça, on va tous être d'accord avec toi... Maintenant, tu peux te poser le problème différemment... Entre les 4 Mo de mémoire, les 80 Mo sur le disque, les 4 ou 8Mhz, du PC d'il y a une quinzaine d'années (et je ne parle même pas de la préhistoire, des ZX81 et des TRS80...), il y a, en gros, un facteur mille.
C'est énorme, un facteur mille, en vitesse c'est plus que la différence entre un piéton et un avion de chasse, en capacité, c'est la différence entre la région parisienne, et une ville comme Mende (Lozère). Dans l'histoire de l'humanité, des "facteurs mille", il n'y en a pas eu beaucoup, alors en 15 ans...
Ma question est alors la suivante : retrouve t'on ces facteurs mille dans la puissance de nos applications... Les exemples données par Koala sont intéressants, ils parlent de facteur 10, 100 peut être...
Où sont les 10 qui manquent, alors?
Francois
J'avoue que je suis un peu perplexe, là dessus... Pour être passé, sur la période, de la position d'acheteur de programmes informatiques à celle de développeur, j'ai l'impression que le cout de développement n'a pas baissé en proportion (et je ne pense pas que les développeurs de base soient mieux payés aujourd'hui qu'il y a 15 ans).
Dans le domaine professionnel, j'aurais même tendance à dire que les prix ont explosé ces dernières années. Regarde ce que tu fais de nos jours avec un budget developpement (prestation extérieure) de 15K€ (pour les vieux, ca fait 100 KF)...
Pour l'informatique grand public, il suffit de voir les dates de sorties des versions (plus le fait qu'une version sur deux est en fait une béta).
Alors, bien sur, l'informatique a permis l'apparition de produits de série. En cinq clics, je peux monter un blog, tache de malade il y a 10 ans. En 20 clics, je peux même monter un forum comme celui ci... Mais là, j'ai l'impression qu'on est davantage dans les "retombées" que dans l'informatique proprement dite...
Francois
Pour cette affaire de performances il y a la question suivante qui se pose :
Pour quelle raison autre que la maitrise fine des ressources je choisirais C++?
parce que si maintenant le choix de C++ pour les nouveaux projets et surtout une question de maitrise de ressources il faut sérieusement se poser la question de l'avenir de C++ est de la manière de le simplifier plus.
d'une part beaucoup choisissent C pour ce type de contrainte et d'autre part
on ne sait pas ce que nous réserve l'avenir coté matériel , peut etre aprés 5 ans avec les multicore il y aura des cores hybrides ou un des processeurs connait nativement cli et l'autre le bytecode, et le switch entre core dependera de ce qu'il faut exécuter.
peut être je délire :) mais il ne faut jamais sous estimer les avancés technologiques et dire que C++ est top comme il est maintenant et il ne faut rien y toucher parcequ'il aura toujours un domaine d'application propre a lui qui est la bonne gestion des ressources n'est pas un bon argument.
Complètement faux. Je ne vois pas du tout ce qui empêche du côté serveur d'utiliser C++ pour envoyer les infos au client léger, comme je te l'ai déjà dit, on fait ça dans tous les langages, et C++ ne déroge pas à la règle. Par exemple Qt propose ce qui est nécessaire pour cela.
- Les performances !
- La maintenabilité du code (avec les templates, j'ai écrit un code parallèle de propagation des ondes 3D avec n'importe quel schéma usuel, ou presque)
- Les frameworks existants
Rien que ces 4 points font que je préfère le C++ aux autres langages.
ça entre dans le cas de maitrise fine des ressources.
ça se discute :), la liberté de c++ fait qu'on a un code varié dans un projet et sincèrement il faut des développeurs plus que moyen pour faire un code maintenable en C++
et la ou je suis d'accord avec toi est si on exploite le meilleure de C++ on peut faire des choses extraordinaires en dev et en maintenance , il faut juste rester dans la simplicité, et je ne sais pas pourquoi j'ai l'impression que C++ comme il est actuellement encourage plus que d'autres langages a avoir un code très compliqué a comprendre.
t'a tout a fait raison mais je ne vois pas ce qui manque dans les librairies d'autres langages et que ça existe qu'en c++.
Que C++ se fasse piquer des parts de marché par php, ruby, python.. ça ne me choque pas ni ne m'effraie. D'un coté on a un langage compilé à typage statique et de l'autre des langages dynamiques. La grande force du C fut d'arriver à produire du code machine aussi compacte et efficace que de l'assembleur à une époque où on n'avait pas le choix pour des raisons qui ont été évoquées précédemment. De nos jours, l'évolution technologique fait que ruby ou python suffisent largement pour tout un pan d'applications. On n'a plus les mêmes contraintes qu'avant. Je m'en réjouis.
En revanche ce qui me choque un peu plus c'est que toutes les implémentations majeures de ces "nouveaux" langages le sont en C et non en C++. Quelque part je trouve que c'est là qu'on mesure un certain échec du C++.
Je ne crois pas que la puissance en développement et la facilité de maintenance soient tout à fait incompatibles avec la simplicité...
Par exemple, une fois que l'on a découvert les fonctions qui agissent sur des écarts, et qui ne sont malgré tout pas *si* compliquées que cela à comprendre, tu peux obtenir un code à la fois facilement lisible, compréhensible, efficace et facile à maintenir...
L'utilisation de for_each en est sans doute l'exemple le plus frappant ;)
Après tout, un code proche de
est clairement explicite:Code:for_each(truc.begin(),truc.end(),foncteur());
et n'est finalement pas plus compliquée à comprendre queCitation:
pour chaque objet qui se trouve entre truc.begin(), et truc.en(), on appelle foncteur
Et c'est encore plus explicite si ton foncteur a un nom correctement choisi :DCode:
1
2 for(iterator it=truc.begin(); it!=truc.end();++it) (*it).fonction();
Et la maintenance est limitée au minimum: Il suffit modifie l'opérateur () du foncteur pour que la modification soit prise en compte partout :D
Et, bien sur, j'ai pris l'exemple de for_each, mais j'aurais pu prendre n'importe quelle autre fonction définie dans <algorithm> ;)
j'ai fait du C++ il y a un certain temps et pour moi la perte de vitesse du C++ par rapport à d'autre langages se trouve (selon moi :mrgreen: ) dans l'absence limites du C++.
je veux dire par là que le C++ n'a pas un usage défini il partage en gros le même marcher que le C alors que c'est pas vraiment sa place ...
un java ou C# sont très orientés et leurs limites bien définies, on sait a quoi ces langages servent. d'ailleurs java et C# sont cantonnés dans des secteurs bien précis, contrairement au C++
La chute de C++, c'est avant tout la chute des MFC. Microsoft a lâché le C++ au profit de C#, ça a fait bien plus de mal que les retards de l'ISO. Plein de monde frustré des MFC s'est réfugié dans .net, et voilà. Mais bon, on tend doucement vers un nouvel équilibre il me semble.
Y'a de moins en moins de projets en C++... c'est surement vrai, mais je pense aussi qu'il est plus exact de dire qu'il y a de moins en moins de projets uniquement en C++ (ce qui implique forcément un besoin moins élevés en développeurs C++). Mais quelque part... j'ai l'impression que le milieu voit une sorte "d'épuration" : les développeurs les moins doués (quel que soit le langage) s'empressent de délaisser C++, et on arrive au même problème avec les autres langages qu'on a en C++ qui est celui de recruter de bon programmeurs. Tous les étudiants apprennent Java par exemple, ça plus autre chose fait que le marché regorge de développeurs Java plus ou moins bidons. Conséquence : il y a des boîtes qui peinent à trouver de bons programmeurs Java. En C++ c'est dur d'avoir de bons CV, en Java c'est dur de les identifier au milieu de tout ce qui existe.
En ce moment je recherche du taff, et à ma grande surprise, mon profil C++ a très rapidement intéressé beaucoup de monde malgré la crise et les offres majoritairement Java/.Net. Au delà de ce qui est visible, il y a encore beaucoup de monde qui recherche des développeurs C++ (avec 2/3 ans expérience). Et y'a pas mal d'offres très intéressantes (d'un point de vue... technique ah ah !).
A côté de ça, les offres Java c'est très souvent la même chose. Bon en même temps je m'y intéresse pas des masses alors je suis mal placé pour en parler, mais j'ai quand même l'impression que si t'es spécialisé Java, soit tu fais des sites web, soit tu vas faire des applis de gestion... et pour moi c'est ch*** comme la pluie (6 mois ça va mais pas plus). Le C++ est encore très en vogue dans le monde de l'industrie il me semble, et en ce qui me concerne, je trouve que ce sont des projets nettement plus intéressants. C'est simplement une affaire de goûts. Faire une appli de gestion, que ce soit en C++ ou en C#, perso ça me fait pas rêver. Alors honnêtement je m'en fiche un peu si ce secteur délaisse C++.
Issam, j'ai l'impression que tu acceptes difficilement le déclin de C++ dans certains domaines. Mais je crois qu'il ne faut pas généraliser à tous les domaines. Et en ce qui me concerne, les domaines en question ne sont pas ce qui se fait de plus intéressant, et c'est là où C++ se montrait le plus pénible / moins productif, alors ça ne me gêne pas trop. Le C++ est très orienté technique c'est vrai, mais il y a quand même pas mal de domaines qui sont par nature très techniques, et pour ceux là, je crois que C++ va rester compétitif encore quelques années.
Cette bidouille se fait principalement au niveau des librairies pour pouvoir offrir une interface commune quelque soit le système ou le compilo utilisé. De ce coté là, Boost fait un travail formidable. L'utilisateur lui n'a généralement pas besoins de bidouiller. L'utilisateur ne veut qu'utiliser du c++ standard et plus ça va, plus ça s'améliore.
Pour en revenir au sujet initial et à un des arguments ("C++ ne s'intéresse pas au DbC") voici quelques vieux articles sur lesquels je viens de retomber :
- http://www.state-machine.com/writings/samek0308.pdf
- http://portal.acm.org/citation.cfm?id=884714
Rajoutez les vieux messages de James Kanze au sujet du pattern NVI (même si ce terme était moins usité à l'époque), des pseuso frameworks (http://www.codeproject.com/KB/cpp/DesignByContract.aspx), les articles de Matthew Wilson et son Impecrfect C++, un papier adressé au comité pondu dans le contexte de la sortie du C++0x, et autres articles (http://www.jot.fm/issues/issue_2006_09/article3/), ...
Non, vraiment, on ne peut pas dire que la communauté C++ n'adresse pas la question de la PpC/DbC.
C'est pas le fait d'avoir quelques articles qui parle de Dbc que la communauté C++ s'intéresse beaucoup a ça.
d'ailleurs quelle sera la réaction d'un developpeur lorsqu'il lira un article du genre http://www.artima.com/cppsource/type_erasure.html ou on découvre l'avis très négatif de Alexander Stepanov sur oop et l'abstraction.
pour les articles il y en a tellement aussi varié au niveau de la manière d'appréhender la conception en c++.
On peut dire c'est bien d'avoir plusieurs points de vue mais un débutant est noyé dans toutes ces possibilités et points de vues et sincèrement je comprends très bien un débutant en C++ lorsqu'il me dit "C++ c'est très compliqué"
Parfois on ne te laisse pas le choix aussi quand ta boit se décide d'utiliser java en majorité tu es obligé de suivre (je vois un peu comment ça se passe chez moi, et j'ai l'impression que C++ tend a réduire de voilure, malgré le fait que les produits sont de bonne factures)....
C'est un peu le problème de tous les langages qui ont été très à la mode. On a pas mal de logiciels développés en C++, qui vieillissent et demandent à être maintenus ou adaptés, mais il devient de plus en plus difficile de trouver des développeurs de niveau suffisant (j'ai actuellement une recherche en cours sur ce genre de poste, et j'avoue être un rien terrifié par les profils que je vois passer...). Un peu parce que l'informatique attire moins les bons élèves qu'autrefois, un peu parce que le C++ passe de mode...
Du coup, on commence à détricoter le système : on garde le logiciel en C++, mais on refait les communications autour en Java, puis on reprend l'interface en C# ou un truc comme ca, à la fin il reste un petit moteur en C++, qu'on maintient jusqu'à ce que son créateur s'en aille, et qu'on le refasse dans le langage à la mode...
Et, forcément, comme la surface du C++ en entreprise se réduit, les écoles forment moins de développeurs C++, et les jeunes s'orientent moins vers ce langage, ce qui précipite l'effet précédent...
Maintenant, il ne faut pas non plus conclure à la mort du C++, juste le fait qu'il est actuellement en train de passer du statut de langage généraliste, à celui de langage spécialisé...
Francois
Ca commence a faire usine a gaz d'acvoir 3 technos en même temps, non?
même si c'est bien fiat ça peu vite être complexe ...
oui la théorie des cercles.Citation:
Et, forcément, comme la surface du C++ en entreprise se réduit, les écoles forment moins de développeurs C++, et les jeunes s'orientent moins vers ce langage, ce qui précipite l'effet précédent...
je ne pense pas non plus qu'il va mourrir, mais il est clair qu'il quitte certains domaines ou java/php/.... semblent plus à l'aise.Citation:
Maintenant, il ne faut pas non plus conclure à la mort du C++, juste le fait qu'il est actuellement en train de passer du statut de langage généraliste, à celui de langage spécialisé...
Bien sur... Mais on l'observe assez souvent dans des PME. En fait, faute de trouver les développeurs qu'on veut dans les technos qu'on voudrait, on choisit ses technos en fonction de ses développeurs. Ca résoud un problème (le pénurie de bons développeurs, et la difficulté à faire évoluer les gens dans un monde où les technologies changent vite) mais ca en crée un autre (la gestion du lien entre les technos, et des chicaias entre équipes quand il y a des bugs...)
Aussi, cette situation apparait assez naturellement quand les applications grossissent. Si tu as, par exemple, une grosse application qui fait des calculs, mais avec un module de gestion, et un IHM un peu moderne, tu vas parfois avoir un langage moteur+IHM (C++, Java, Delphi, C#), parfois deux, mais au delà, tu auras souvent des petits bouts écrits dans des langages spécialisés : VBA autour des exports utilisateurs, PHP si tu as un peu de Web, SQL si tu as une base de données, des bouts de scripts OS pour les mises à jour... Petit à petit, tu vas voir coexister plusieurs technologies.
Maintenant, le mélange n'est pas aussi difficile qu'on le croit, cela demande une bonne réflexion sur l'organisation des tâches (notamment sur les responsabilités de chacun en terme de maintenance), mais comme c'est devenu une situation assez courante, les OS modernes prennent cette coexistence en compte, et le rendent relativement paisible...
Francois
Ca c'est bien vrai
Avec un peu de chance, ça le fera réfléchir (non pas Stepanov, mais le développeur) :ccool:
Je comprends tout à fait ça. Je considère le c++ comme non seulement compliqué, mais même extrêmement compliqué. Bon, faut dire que j'en fais que 2 semaines par an :aie:
La marge entre débutant et expert est à mon avis très très vaste en ce qui concerne le c++. On n'y peut rien, c'est comme ça. Remédier à ça, ça serait créer un nouveau langage... et c'est ce que certains ont fait, avec tout ce que ça comporte comme réussites et échecs :mrgreen:
Bof.
C'est juste qu'en C++, il faut comprendre un minimum les trucs qu'on utilise, alors que les autres langages sont plus permissifs et permettent de coder sans vraiment comprendre comment les choses fonctionnent.
Je trouve que ça va plus loin que ça. Effectivement il faut comprendre ce qu'on utilise, mais pour comprendre à un niveau d'expertise élevé, alors ça implique de connaître une quantité de subtilités vraiment imposante. On ne peut pas se contenter de lire le standard du c++ et se dire ensuite, ok c'est bon, j'ai pigé. Là je mets de coté toute la librairie. Juste les core functionalities du langage.
a- D'accord. Mais, si par "communauté" tu entends "gens qui développent pour manger essentiellement" (on va dire), il ne faut pas se leurrer, ce sera exactement la même chose en Java et en C#. Ce problème je l'étends au LSP : le terme "est-un" est un faux ami qui fait que les gens dériveront des ListeTriee de Liste sans même comprendre pourquoi ce n'est pas bon. Après tout, "une liste triée est bien une liste..."
b- Chose qui sort d'un C++ien et qui fait des émules dans la communauté des érudits C++ (histoire de mieux cerner les sous-communautés). Voilà une communauté qui se pose d'autres questions de design.
ben si on vient en C++ et que l'on s'attend à ce que ça soit du JAVA, effectivement c'est compliqué.
Si on fait l'effort d'utiliser correctement la librairie standard, on comprend mieux
AHMA, si tu répètes ce genre de chose en face de Stepanov, il te mettra un bon coup de poing sur le nez (mérité) :mrgreen:. Le bonhomme a passé environ trente ans de sa vie à réflechir et expérimenter sur l'abstraction ! Et s'il n'est pas spécialement emballé par l'approche orienté objet c'est justement car il pense que l'OO est une philosophie douteuse pour abstraire les problèmes. ("philosophically unsound")
Citation:
Envoyé par Stepanov
Citation:
Envoyé par Stepanov
C'est la tout le malheur, si oop est a éviter , alors pourquoi on l'étudie a l'école et pire pourquoi la majorité des projets sont fait avec oop.
et si on raisonne bien ça reste un point de vue même si ça vient d'un guru, parce que si on suit ta logique on peut dire que C++ est a éviter parce que le fameux linus trovalds affirme que C++ est un langage horrible et il faut développer en C.
donc finalement beaucoup de courants se dégagent en C++ , et le développeur est noyé dans tout ça, et il entend beaucoup des phrases genre " Non tu comprends pas" dans cette communauté de C++, a force il sera traumatisé:).
Quelle logique ? Je suis d'accord avec toi, c'est un point de vue, d'autant plus intéressant qu'il vient d'un "guru" (tout comme les propos de linus sur le C++ portent à réfléchir), mais en aucun cas une vérité révélée.
Je voulais juste pointer qu'affirmer que Stepanov a "un avis très négatif sur l'abstraction", bah c'est juste complètement idiot.
C'est au contraire plutôt intéressant de constater que certaines personnes dans la communauté C++ recherchent l'abstraction sans passer forcément par l'OO (qui pour le coup ressemble dans ta bouche à une vérité révélée :mrgreen:). Le fait que de nombreux courants se dégage n'est-il pas l'indice le plus fort que la communauté C++ s'intéresse tout particulèrement à la conception, au point d'envisager des approches très différentes et d'accepter plusieurs paradigmes en son sein ?
avoir plusieurs approches au niveau conceptuel c'est très bien, d'ailleurs on peut combiner oop et generic dans un projet pour avoir une conception nikel.
le probléme réside au fait qu'on a même pas le temps de concevoir, on bataille avec les frameworks techniques encore, juste un exemple de base de données ou chaque boite a son propre framework C++ soit fait maison autour de odbc, oci ou autre, soit récupéré du web, il y en a tellement d'ailleurs :) , alors si on choisis un on passera beaucoup temps a debuger s'il ya un pb vu que forcement il nya pas une grande communauté qui utilise ce framework donc pas assez de retour.
pour un universitaire par exemple le c++ c'est très bien , il a tout son temps de bien faire les choses, mais en entreprise on veut se focaliser sur le métier et toute la complexité technique on veut l'éviter a tout prix, d'autant que le planing est généralement serré pour réaliser les projets, et finalement on fait du C# ou Java ou autre.
on peut se poser la question sur l'absence de la comité de standardisation des années pour évoluer le langage et surtout les librairies techniques pour éviter tout ce casse tête de choix et simplifier cette couche technique qui a fait beaucoup de dégâts a C++.
Le fait est qu'il a toujours fallu choisir, si tant est que le choix soit possible, la moins mauvaise solution...
La POO a longtemps été perçue comme la moins mauvaise solution, car c'est celle qui apportait un meilleur rapport complexité / problème, et de nombreux langages (y compris parmi les plus récents du point de vue historique) se sont engouffrés dans la brèche...
Les "grands penseurs" ont fini par remarquer que, dans certaines situations, la POO présente une série de lacunes, ne serait-ce que du point de vue de la granularité, de la flexibilité ou de l'obligation qui nous est faite de dupliquer encore et encore du code chaque fois que nous sommes confrontés à un problème similaire mais manipulant des données différentes...
Un simple exemple pourrait être n'importe quelle pile, file liste ou arbre binaire: En POO exclusif (comprend: sans avoir recours aux template et sans avoir une "super classe de base" object), si tu veux créer trois files contenant des données différentes (une file de A, une autre de B et une troisième de C, par exemple), tu te trouve face à l'obligation de réécrire trois fois un code strictement identique pour ta file, simplement pour l'adapter au type qu'elle manipule réellement.
Java et C# ont contourné cette restriction en décidant que tout type dérive d'un type de base "object" (quelle que soit son orthographe exacte), mais décidant de "tronquer" LSP ce qui les a obligés à prendre d'autres décisions restrictives vis à vis, par exemple, de l'héritage multiple.
La programmation générique est apparue le jour où les "grands penseurs" se sont rendus compte que si nous nous intéressons plus au comportement d'un objet qu'à l'objet manipulé, nous pouvons nous éviter bien des problèmes du à la répétition du code, le type de la donnée elle-même devenant plus ou moins secondaire.
Cette optique est-elle plus complexe :question: assurément car cela implique qu'il faille penser plus loin que le simple "j'attends tel service de tel type de donnée".
Quant à savoir si c'est "la moins mauvaise" solution, je dirais que chacun peut trouver sa propre réponse en fonction de la prépondérance qu'il donne à chacun des avantages et des inconvénients.
D'aucuns trouveront que cela rend la conception exagérément complexe par rapport au gain de flexibilité et à la capacité d'obtenir quelque chose pouvant travailler avec n'importe quel type de donnée, d'autres trouveront, au contraire, que la complexité ajoutée à la conception est largement "payée" par la souplesse obtenue.
Le premier groupe préférera sans doute rester dans une approche OO classique, le second concevra tout sur une base générique.
Et entre ces deux extrêmes, nous trouverons une quantité phénoménale de cas alternatifs plus ou moins proche de l'un ou l'autre, en fonction des capacités ou de l'habitude de chacun à manipuler la programmation générique.
Bien sur que cela reste un pur point de vue...Citation:
et si on raisonne bien ça reste un point de vue même si ça vient d'un guru, parce que si on suit ta logique on peut dire que C++ est a éviter parce que le fameux linus trovalds affirme que C++ est un langage horrible et il faut développer en C.
Et je suis persuadé que linus tovald n'est absolument pas le seul à estimer que C est meilleur que C++.
Tout comme je suis certains de trouver autant de gens qui détestent C++, que de gens qui détestent C# ou Java (ou tout autre langage d'ailleurs) et qui ne veulent pas entendre parler d'autre chose que d'un de ces langages...
C'est sans doute pour cela qu'il n'existe pas un langage unique et universel ;)
De tous temps, tout le monde a eu tendance à "tirer la couverture à soi"...Citation:
donc finalement beaucoup de courants se dégagent en C++ , et le développeur est noyé dans tout ça, et il entend beaucoup des phrases genre " Non tu comprends pas" dans cette communauté de C++, a force il sera traumatisé:).
Il suffit de voir le succès de tous les débats qui tentent de comparer deux langages, tous sites confondus.
Ceci dit, rien ne t'empêche malgré tout de n'utiliser que le paradigme POO du C++, et de n'utiliser que la S(T)L si tu le souhaite ;)
Après, tu ne peux pas reprocher à la communauté d'essayer "d'éduquer" les gens pour qu'ils évoluent vers une conception plus générique...
C'est, finalement, le but de toute communauté basée autour d'un langage de programmation ;)
Après tout, il est dommage d'avoir un langage puissant disposant de mécanismes capables de nous faciliter énormément les choses (en nous évitant entre autres de réécrire toujours la même chose adaptée), et de ne ne pas en tirer pleinement parti ;)
On peut évidemment reprocher à "ceux qui savent" d'oublier un peu facilement que ce qu'ils considèrent comme "allant de soi" est parfois très complexe pour quelqu'un qui débarque, mais c'est, malheureusement, un problème qui est présent tous langages ou technologies confondus :D