Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Tu viens de dire qu'en C++ il n'y a pas de volonté d'unifier. C'est une erreur. En Java, c'est la même chose, il y a pleins de frameworks différents et chacun a son style. Idem en C++.
Bref, tu ressasses les mêmes arguments, nous aussi, tu dénigres le C++ par ta méconnaissance de ce qui se passe dans les autres langages, ...
pour l'unification on ne peut pas dire qu'il y a tout ou rien , c'est vrai que d'autres langages ont le même problème mais au moins il y a une volonté pour unifier ou pour les problèmes récurrents techniques de base on a des spécifications.Envoyé par Matthieu Brucher
il y a l'OMG qui a commencer a faire cette effort louable et j'espère que ça va aboutir a quelque chose.
et effectivement cette discussion commence a tourner en rond , surtout si on est persuadé qu'il faut prendre ou laisser C++ et aucune critique ni changement n'est tolérable, finalement a quoi bon nous sommes tous des experts et on maitrise parfaitement les rouages de C++
Cette volonté n'existe pas...
En C++ on a moins de problèmes avec la diversité des bibliothèques, justement parce qu'il est préconisé de de programmer de manière non intrusive, en utilisant des fonctions libres à la place de fonctions membres.
C'est encore plus intéressant avec les concepts ; par exemple, une bonne bibliothèque de traitement de polygones manipule les polygones que ceux-ci soient représentés par la classe interne du projet ou non.
sincèrement je suis loin d'être fun de java
et on a plusieurs implémentations de ces specs donc on a pas a connaitre énormément de façon de faire pour la couche technique, par contre pour la partie graphique ils ont le bordel aussi.
et je suis conscient que historiquement on a pas des specs en C++ pour la couche technique et chacun fait comme bon il lui semble.
la différence finalement c'est qu'en java on a plusieurs implémentations mais une seule interface et en C++ plusieurs interfaces et dans ce cas on bénéficie pas bcp de notre expérience technique a chaque fois il faut se reformer sur une librairie technique.
J'avoue que je comprends de moins en moins de quoi tu parles Issam_Lahlali, ton dernier message n'a pas grand sens.
A ce propos:
Je cite:ce qui m'intéresse dans les évolutions est surtout la simplification de la couche technique, et d'ailleurs C++0x ou C++03 ne se focalise pas trop a la simplification de la couche technique.
Note en particulier le second point.
On pourrait argumenter que l'ajout de tas de fonctionnalités au language le rends plus complexe, mais si on prends le temps de bien étudier attentivement les dites fonctionnalités (ce que tu as fais n'est-ce pas?), on se rends compte que la plupart visent a simplifier l'écriture, font sauter des barrières inutilement restrictives et simplifie la spécialisation du language pour les domaines d'applications...et encore d'autres choses.
Le c++ de demain sera encore plus simple, même si il sera toujours possible de l'écrire comme aujourd'hui... de la même façon qu'on encore peut faire du C with Classes.
J'ai le dernier livre de Stroustrup qui explique la programmation a des débutants, en utilisant C++. Il parviens a expliquer les philosphies de base sans utiliser ni pointeur ni autre concepts subtil et propice a l'erreur jusque la moitié du livre qui fait 1200 pages. Il y décris le processus de développement (avec ses erreurs) d'un parseur pour une calculatrice. Le tout est simplement "simple". Il se fout de la complexité qu'on peut trouver dans des tas d'autres applications, parcequ'il n'en a tout simplement pas besoin.
On en arrive a ce qui a déjà été dit plusieurs fois ici: la seule vrai complexité du C++ c'est ce que coute la liberté. La libertée de philoshophie (multiparadigme) qu'on peut suivre aveuglément ou composer selon pertinence, liberté de niveau d'abstraction (ne pas toucher soit même a la mémoire ou au contraire toucher a tous les niveau d'abstractions, des plus bas aux plus hauts), etc. Le tout sans avoir a changer de language.
Alors c'est sur qu'avoir un language confiné dans des philosophies bien précises est plus confortable, mais ce n'est pas approprié pour toutes les applications.
Il n'y aurait pas de C++, il y aurait un équivalent à la place. On a besoin de sa "complexité" parceque qu'on a besoin d'avoir le choix.
Souvent.
En tout cas dans les domaines ou j'ai travaillé c'est le cas
C'est le reflet réaliste des différences dans les hardwares. Sans ça on gacherai le potentiel de tas de machines. Ca fais aussi parti du choix.et je suis conscient que historiquement on a pas des specs en C++ pour la couche technique et chacun fait comme bon il lui semble.
je ne vois pas en quoi le c++0x a créer une révolution pour que c++ devient a la porté des novices.
ça apporte d'autres fonctionnalités et malheureusement l'évolution la plus importante est laissé de coté il s'agit des concepts, en fait on a parler beaucoup de programmation générique et ces bien faits mais le manque de concepts présente une grande lacune pour la conception orienté génériques.
ce qu'il faut surtout c'est une spécification de la couche technique et un developpeur ne peux finalement qu'a apprendre une seule maniere de faire au niveau couche technique et forcement plusieurs implémentations.
ca peut paraitre mission impossible mais dés qu'on a une spec par exemple pour database, crois moi rapidement on aura les wrappers adéquats pour les librairies databases déjà existante, finalement c'est juste des redirections.
le but est d'avoir une seule maniere uniforme pour la couche technique et a mon avis ca facilitera pas mal de choses.
d'un coté on a pas a se former a chaque fois sur d'autres librairies et d'autre part le switch d'une implémentation a une autre est trés aisé.
combien de fois on se rend compte a la phase de test qu'une librairie ne tient pas la charge ou n'est pas performante ou peut etre manque d'une fonctionnalité pour une évolution.
finalement je suis pour une spécification de la couche technique , surtout que cette couche est très maitrisé actuellement alors pourquoi laisser cette jungle.
et j'entends par couche technique : database,xml,distribué,MOM, et autre librairie qui fait partie de la tuyauterie technique.
la solution dans le monde C++ est de ne pas utiliser une librairie technique directement mais passer par notre couche d'abstraction oop ou generique pour éviter d'être couplé directement avec la librairie en question.
et c'est ce que j'ai pratiquer dans pas mal de projets C++ ou on se rend compte que c'est primordial vu qu'au dernier moment on se rend compte qu'il faut changer de librairie ou des fois proposer deux solutions alternatifs en depend du contexte (utilisation de librairie payante ou free par exemple).
et finalement je me demandais pourquoi chaque boite a besoin de sa propre abstraction, pourquoi ne pas avoir des specs pour la couche technique et éviter toute cette complexité.
on sait que c'est bien d'avoir plusieurs implémentation pour la couche technique mais l'idéal est d'avoir une seule abstraction pour cette couche ça ne peut être que très bénéfique pour tout le monde.
Il faut arrêter de considérer les bibliothèques comme des couches techniques qui nécessitent une formation pour être utilisées...
Une bibliothèque, c'est une bibliothèque, un développeur décent ne devroit avoir aucun problème pour la manipuler, ni même en étudier le code et la modifier en besoin.
Le problème principal de la génération de développeurs J2EE, c'est qu'ils sont incapables de faire quelque chose s'ils ont pas une solution toute faite par Sun ou IBM.
le probléme n'est pas juste la formation, imagine que tu dois changer de librairie technique a un moment donné pour une raison ou pour une autre, si le code est fortement très couplé avec la librairie je ne te dis pas le travail a faire pour l'adapter a une autre librairie.
j'en ai déjà fait l'expérience une fois et c'était catastrophique et après j'ai pris l'habitude de faire abstraction de la couche technique dés que possible.
J'ai l'impression que c'est une caractéristique de Stroustrup et de quelques autres bons auteurs (personnellement je mettrais Sedgewick dans cette liste). Quand on les lit, quand on comprend, c'est simple, élégant, on en pleurerait...
Maintenant, le problème, c'est que c'est un peu comme les maths en terminale, c'est joli, élégant, sympa... pour les trois qui suivent...
Pour tous les autres, c'est juste trop abstrait, et incompréhensible.
Honnêtement, j'ai l'impression que Stroustrup nous démontre un vieux dicton, qui affirme que l'enfer est pavé de bonnes intentions. Le C++ moderne, c'est effectivement sympa, abstrait et élégant, mais c'est horriblement élitiste (au sens où cela s'adresse à un tout petit public)
Heureusement, il y a Koenig (et Moo ...)
Francois
Il est vrai que l'abandon des concepts pour la prochaine norme est domage, mais c'est très loin d'être la seule amélioration...
Dans les améliorations finalement bien plus intéressantes, afin de supprimer un peu de la verbosité de certains concepts tout en apportant de la simplicité et de auto commentaire, on peut citer les lambda expressions, les lvalue references, les fonctions deleted ou la détermination automatique des types...
Et je ne parle ici que des fonctionnalités dont j'ai entendu parler et pour lesquelles j'ai une vague idée de ce que cela apporte.
Tu disais plus haut que, si les lambda expressions étaient abandonnées, on trouverait du monde pour dire que l'on n'en a pas forcément besoin...
Et tu as raison: aucune des nouvelles fonctionnalités que j'ai citée n'est absolument nécessaire étant donné que l'on fait sans depuis près de trente ans.
Cependant, chacune de ces nouvelles fonctionnalités a, justement, pour but de permettre une meilleure mise en oeuvre et trouve un intérêt en simplification du travail.
Il faut comprendre que SQL, XML, DOM, SAX, MOM, HTTP, UDP et tant d'autres sont eux même autant de spécifications qui ont leur propre standard, qui évoluent à leur propre rythme...ce qu'il faut surtout c'est une spécification de la couche technique et un developpeur ne peux finalement qu'a apprendre une seule maniere de faire au niveau couche technique et forcement plusieurs implémentations.
ca peut paraitre mission impossible mais dés qu'on a une spec par exemple pour database, crois moi rapidement on aura les wrappers adéquats pour les librairies databases déjà existante, finalement c'est juste des redirections.
Si tu viens à figer dans la norme d'un langage des choses relatives à des normes en vigueur à un instant T, cela implique soit que, à l'instant T+1 (qui correspond à la sortie de la "nouvelle norme" de ces spécifications) le langage devient obsolète, simplement parce que, justement, il risque de ne plus supporter la nouvelle norme, soit cela oblige à modifier la norme du langage, ce qui n'est absolument pas envisageable lorsque l'on connait les différentes prescriptions que doivent respecter les normes ISO...
Ce n'est pas au langage à prendre ces spécifications externes en compte mais à une bibliothèque dédiée qui utilise, autant que faire se peut, la norme "la plus à jour" du langage pour implémenter la "dernière norme / spécification" du protocole ou du concept qu'elle s'est donné comme objectif de respecter.
La couche technique doit regrouper ce qui est dépendant du langage et qui est à considérer comme le plus grand commun diviseur des différentes possibilités offertes par le langage.le but est d'avoir une seule maniere uniforme pour la couche technique et a mon avis ca facilitera pas mal de choses.
Autrement dit, ce que tu trouve actuellement dans les espaces de noms std et std::tr1 plus les éventuels ajouts décidés par la nouvelle norme.
Tout ce qui est tiré d'autres protocoles / normes / spécifications n'a strictement rien à faire dans le langage, à moins qu'il n'y ait effectivement une unification réelle et remarquable de la manière de les utiliser (par exemple, ce qui a été fait au niveau des threads)
Qu'est ce qui n'est pas aisé dans le fait de passer de la bibliothèque "Alpha" à la bibliothèque machin chosed'un coté on a pas a se former a chaque fois sur d'autres librairies et d'autre part le switch d'une implémentation a une autre est trés aisé.
Le fait que l'une ne fournit des fonctions dont tous les noms sont en minuscule alors que l'autre fournit des noms avec la première lettre en majuscule
Le fait que l'on appellera dans l'une la fonction instance et dans l'autre la fonction getInstance
Le fait qu'il faille, éventuellement invoquer une fonction init avant de faire quoi que ce soit
Le fait que, dans une bibliothèque, un type donné soit nommé TTrucMachinChose et dans l'autre BiduleMachinChose
Laisse moi rire, si tu n'est pas capable de t'adapter à des changements finalement aussi mineurs, tu as peut être loupé ta vocation
Tu crois sans doute que c'est mieux dans d'autres langagescombien de fois on se rend compte a la phase de test qu'une librairie ne tient pas la charge ou n'est pas performante ou peut etre manque d'une fonctionnalité pour une évolution.
Ou peut être crois tu réellement que le fait qu'il n'y ait, à ta connaissance, qu'un seul framework adapté à un besoin particulier limite ce risque
Au contraire, j'aurais tendance à dire que plus tu as de bibliothèques aptes à fournir un service donné, plus tu as de chances d'en trouver une qui sera plus adaptée à une montée en charge ou à un besoin particulier, voire, à trouver la bibliothèque que tu pourra plus facilement adapter à tes besoins...
Ce n'est pas du ressort de la norme d'un langage...finalement je suis pour une spécification de la couche technique , surtout que cette couche est très maitrisé actuellement alors pourquoi laisser cette jungle.
et j'entends par couche technique : database,xml,distribué,MOM, et autre librairie qui fait partie de la tuyauterie technique.
Au mieux est-ce du ressort de la spécification d'une bibliothèque, et surement pas de celle qui est sensée servir de base minimale.
Parce que les specs pour les domaines dont tu parle évoluent à leur propre rythme et font partie de standards sur lesquels le C++ n'a strictement aucune emprise...la solution dans le monde C++ est de ne pas utiliser une librairie technique directement mais passer par notre couche d'abstraction oop ou generique pour éviter d'être couplé directement avec la librairie en question.
et c'est ce que j'ai pratiquer dans pas mal de projets C++ ou on se rend compte que c'est primordial vu qu'au dernier moment on se rend compte qu'il faut changer de librairie ou des fois proposer deux solutions alternatifs en depend du contexte (utilisation de librairie payante ou free par exemple).
et finalement je me demandais pourquoi chaque boite a besoin de sa propre abstraction, pourquoi ne pas avoir des specs pour la couche technique et éviter toute cette complexité.
Il est déjà difficile d'assurer le fait que C++ utilise la norme "officielle" du C dont il hérite pourtant, alors, comprend que cela devienne purement et simplement impossible au sujet de normes qui n'ont strictement rien à voir, surtout si l'on en vient à multiplier les normes à prendre en compte...
Toi qui plaide en faveur d'une simplification, tu obtiendrais justement l'effet strictement inverse, avec une norme qui devrait être mise à jour tous les trois mois, et pour laquelle les fournisseurs de compilateur auraient les plus grandes difficultés à assumer la mise en oeuvre, du moins, si tu veux éviter qu'une partie de la norme ne devienne trop rapidement obsolète.
Pour ce qui est suffisamment stable et implémenté de manière suffisamment homogène uniquement...on sait que c'est bien d'avoir plusieurs implémentation pour la couche technique mais l'idéal est d'avoir une seule abstraction pour cette couche ça ne peut être que très bénéfique pour tout le monde.
A méditer: La solution la plus simple est toujours la moins compliquée
Depuis maintenant près de vingt ans, microsoft s'ingénie à nous faire croire que l'informatique est facile...
Oui, l'utilisation de l'outil informatique est facile, enfin... on se comprendMais cela ne veut absolument pas dire que la conception et la programmation le soient...
Bien sur que la conception, la modélisation et la programmation ont quelque chose d'abstrait, mais comment pourrait-il en être autrement quand le but même de ces trois mots est... d'arriver à fournir une application qui manipule... des vues de l'esprit
Après tout, c'est parce que tu considérera qu'une personne peut être représentée par son nom, son prénom, sa date de naissance et son adresse que tu décidera du nombre et du type des différents membres et fonctions d'une classe Personne
Le problème de l'écriture d'un livre est toujours le même: que doit on considérer comme acquis ou comme prérequis afin d'assurer la compréhension du lecteurHonnêtement, j'ai l'impression que Stroustrup nous démontre un vieux dicton, qui affirme que l'enfer est pavé de bonnes intentions. Le C++ moderne, c'est effectivement sympa, abstrait et élégant, mais c'est horriblement élitiste (au sens où cela s'adresse à un tout petit public)
Heureusement, il y a Koenig (et Moo ...)
Francois
Si l'on place la barre trop haut, ou si l'on s'intéresse à un domaine trop particulier, on limite l'audience que peut avoir l'ouvrage.
Si l'on place la barre trop bas et que l'on décide de mélanger l'apprentissage de la conception ou de l'algorithmie avec l'apprentissage du langage, on en arrivera à devoir écrire trois volumes afin de faire un tour sans doute encore tronqué.
Dés lors, quel est le juste milieu
Et encore, je ne parle pas de l'optique qui consisterait à fournir un ouvrage orienté "besoin" plutôt qu'un ouvrage orienté "syntaxe"
?[...]
Honnêtement, j'ai l'impression que Stroustrup nous démontre un vieux dicton, qui affirme que l'enfer est pavé de bonnes intentions. Le C++ moderne, c'est effectivement sympa, abstrait et élégant, mais c'est horriblement élitiste (au sens où cela s'adresse à un tout petit public)
Si je me souviens bien, le chapitre dévoué à la calculatrice sert à montrer par l'exemple les principes de bases de la programmation : variables et fonctions. Je ne crois même pas que le concept de "classe" ait déjà été introduit à ce moment.
Tu considères que les variables et les fonctions sont des concepts "horriblement élitistes" ?
peut être on parle pas de la même chose
la spec JDBC existe bien en java comme la spec EJB,JMS et autres et je ne vois pas c'est quoi le pb d'avoir la même chose en C++.
voila les avantages d'une spec pour la couche technique:
- je ne cherche pas quel librairie adapté dés le debut, ou je peux faire des erreurs de choix nuisible a tout le projet vu que je maitrise pas forcement dés le depart toutes les complexités qui vont venir aprés.
- un developpeur dans ces etudes peut se focaliser que sur ces librairies et dés qu'il integre la boite il sera plus productive, il connait deja la librairie de la couche technique, actuellement c'est mission impossible vu le nombre de librairie.
- et le plus gros avantage c'est le fait d'avoir une librairie homogène ou la communication entre sql,xml,... soit très facile.
on peut pas me dire que ça sert a rien une tel spec de la couche technique
et si on voit que c'est impossible , alors comment le monde java ont réussi a le faire en proposant plusieurs specs pour la couche technique.
Si je me souviens bien, le chapitre dévoué à la calculatrice sert à montrer par l'exemple les principes de bases de la programmation : variables et fonctions. Je ne crois même pas que le concept de "classe" ait déjà été introduit à ce moment.
En fait il a la bonne approche: il n'explique pas comment tout est fait, il explique juste comment utiliser ce dont on a besoin.
La plupart du temps quand on développe c'est effectivement ce qu'on demande. Et là il démontre surtout qu'on a pas a se prendre la tête avec comment les outils qu'on a marchent exactement quand on veut simplement utiliser leur fonctionalité.
Il rentre dans les détails par la suite quand ça deviens nécessaire, a partir de l'implémentation d'une classe vector par exemple.
J'ai remarqué moi même ma tendance a mal expliquer des choses parceque j'essayais d'expliquer le fond avant l'utilisation. En fait la plupart du temps on utilise l'abstraction justement pour s'eviter d'avoir besoin de cherche dans le code comment ça marche. Du coup je lis ce bouquin pour voir comment expliquer plus simplement.
Enfin bref, encore hors sujet ^^
Il y a plusieurs versions des spécs, ce ne sont pas des specs officielles, aps forcément suivies car ne répodnant pas à tous les besoins, ...
Si je comprends bien , on arrive pas a cerner jusqu'à maintenant ce qu'il faut pour utiliser une base de données relationnel.
alors dans ce cas je comprends très bien pourquoi tellement de complexité dans le monde informatique
et pour JDBC la majorité de projets java l'utilise ainsi que d'autres spec comme EJB et JMS si c'est nécessaire.
et s'il ya un pourcentage trés faible qui n'est pas adressé par cette spec, il fera comme il le fait aujourdhui, mais pour la majorité on gagnera en simplicité et flexibilité.
@Issam_Lahlali
Pourquoi ne pas te lancer dans la formulation de ces fameuses specs, après tout, il faut bien que quelqu'un commence ? Je comprends ta frustration par rapport à ce qui se fait dans le monde de java par exemple, ou C#. En ce qui concerne ce dernier, on notera que C++/CLI est peut être un pas important en ce sens, rendu possible par la présence d'un environnement d'exécution défini (le CLR). Je suis en train de me dire que C++/CLI est ce C++ simplifié que tu cherches en vain (si on reste en /clr:pure). En plus, c'est standardisé par ECMA, et je trouve personnellement que c'est vachement bien foutu (la contribution d'Herb Sutter n'y est pas étrangère).
Il faut bien te dire que ce n'est pas un hasard s'il existe autant de pilotes SQL que de SGBD(R)...Si je comprends bien , on arrive pas a cerner jusqu'à maintenant ce qu'il faut pour utiliser une base de données relationnel.
alors dans ce cas je comprends très bien pourquoi tellement de complexité dans le monde informatique
C'est parce que la norme SQL doit être, à peu de chose près, aussi épaisse que la norme C++ et que rares sont les SGBD(R) qui la respectent tout à fait (de mémoire, il me semble que c'est PosGres qui est le plus proche de la norme).
Dés lors, comment veux tu intégrer dans la norme du langage la partie technique permettant de faire le lien
Tu peux, effectivement, décider de définir des specs pour une bibliothèque utilisant un langage particulier qui soit indépendante de la norme du langage (comme l'est JDBC), mais tu ne peux absolument pas envisager de définir ces sepcs dans la norme du langage lui-même car ce n'est absolument pas son domaine.
C'est le but, on ne peux pas introduire la norme de SQL dans C++ c'est tout a fait normale, mais il nous faut une api commune pour utiliser une base de données.
pour les grands projets surtout ça devient primordial de ne pas avoir un couplage fort avec les librairies techniques, il faut passer par un framework fait maison pour rediriger vers les librairies réels.
cette problématique je l'est eu plusieurs fois ou pour N raison on a besoin d'utiliser une autre librairie et on peut avoir 2 librairies utilisés pour le meme besoin, par exemple pour le MOM on etait obliger une fois d'utiliser Tibco et ActiveMQ pour adresser des clients qui ont énormément de messages (Tibco) et ceux qui ont moins de message et ne veulent pas investir dans Tibco.
et pour cette raison que je me demande pourquoi j'ai a faire cette abstraction, n'est il pas possible de le faire d'une maniere uniforme et unifié.
Répondre avec citation
Partager