Discussion :

[koala01]

Ben, java fait le distinguo entre l'interface et la classe, et c'est, quelque part, la "pirouette" qui lui a permis d'interdire l'héritage multiple

Parce que, il faut bien se rendre compte que, bien que les mots clés soient différents, le fait d'implémenter une interface java est en réalité... un héritage caché

Ce qui est peut être encore pire, car, en gros, cela revient à dire "c'est interdit, mais faites le quand même (sans vous en rendre compte )": la logique du raisonnement m'échappe quelque peu

Je suis entièrement d'accord avec le fait qu'il est souvent largement préférable de recourir à l'agrégation plutôt qu'à l'héritage (surtout si cela le fait devenir multiple ), mais, dans certains cas, l'agrégation devra viser à... exposer quasiment l'ensemble de ce qui aurait de toutes manière été exposé si l'héritage multiple avait été utilisé, et là, c'est "se faire du mal" pour pas grand chose

Même si je suis d'accord sur le fait que les cas dans lesquels l'héritage multiple est intéressant sont pour le moins rares, je considère comme une erreur que de vouloir l'interdire.

Peut-être ai-je une trop haute estime du "commun des développeurs", mais je trouve que c'est au développeur de placer ses limites, et qu'elles ne doivent pas être imposées par le langage, tout comme je trouve que l'idée de déresponsabiliser le développeur est un pas dans la mauvaise direction que trop de langages ont fait...

[JolyLoic]

Depuis le moment où j'ai appris l'existence des principes « préférez la composition à l'héritage » et « une classe hérite pour être réutilisée dans un contexte polymorphe et non pour réutiliser les fonctions de la classe mère » , je n'ai pas rencontré de cas où l'héritage multiple s'imposait (sauf pour les bidouilles du style boost::noncopyable ou boost::enable_shared_from_this, qui n'auraient pas lieu d'être en D).

Je développe pas mal en c#, qui a les mêmes restrictions que java (ou D ,donc) à ce sujet. Et le manque d'héritage multiple me gêne régulièrement, m'obligeant à dupliquer du code. Dans la plupart des cas, une solution à héritage simple serait possible, mais il faudrait pour ça modifier une classe intermédiaire à laquelle je n'ai pas accès. Est-ce que j'utilise des classes intermédiaires d'une bibliothèque mal conçue ? Je ne le pense pas particulièrement. Et en tout cas un héritage multiple résoudrait ce problème.

Tout qui dérive d'Object, pas d'héritage multiple... Ça ne donne pas trop envie d'essayer D pour l'instant. Tu parlais d'usages avancés des templates... Tu pourrais détailler ?

[Goten]

Je crois qu'il parle de if static (à la compilation) qui permettent de faire de la métaprogrammation plus aisément ?

Mais faut vraiment que je regarde la gestion des templates de D vu les éloges que tu en fais, et le peu de reproche que j'ai à faire à ceux du C++. (sauf peut être le manque de variadics templates ? :p)

Quand au tout Objet : ça me fait assez peur aussi, et je rejoins les autres au dessus, on a tendance à nous servir de l'objet à toute les sauces beaucoup trop souvent je trouve.
La puissance du C++ vient du fait qu'il combine plusieurs paradigmes, par exemple objet + généricité qui sont très efficace.
Quand à l'héritage multiple je suis pas tout à fait d'accord avec Florian et Koala, c'est très utile notamment d'un point de vue conception de bibliothèque (mais pas que là), si tu veux faire des policies pour gérer le comportement de ta classe.

[koala01]

Quand à l'héritage multiple je suis pas tout à fait d'accord avec Florian et Koala, c'est très utile notamment d'un point de vue conception de bibliothèque (mais pas que là), si tu veux faire des policies pour gérer le comportement de ta classe.

tu dois confondre, je suis plutot du coté des partisans de l'héritage multiple... Même si je reconnais qu'il faut l'utiliser avec prudence

"Connais ton ennemi"

[Florian Goo]

Des if et des for statiques en C++, ce serait franchement très chouette.

[Florian Goo]

Et pour l'héritage multiple… c'est vrai qu'une fonctionnalité en plus, c'est toujours un avantage.
Oui, finalement je rejoins ton avis, Koala (même si hériter d'une classe non-interface reste à éviter, l'héritage étant le couplage le plus fort).

[screetch]

les IF statiques, les templates sur les chaines (super pratiques pour les regexp ou pour les chaines formattées connues a la compilation) c'est ce ue je trouve super interessant.

[Goten]

Le if statique s'émule très bien, c'est juste plus verbeux :/

[deadalnix]

Et pour l'héritage multiple… c'est vrai qu'une fonctionnalité en plus, c'est toujours un avantage.
Oui, finalement je rejoins ton avis, Koala (même si hériter d'une classe non-interface reste à éviter, l'héritage étant le couplage le plus fort).

Cela permet d'avoir un mécanisme d'héritage bien plus simple dans le bas niveau. Celui-ci est d'ailleurs relativement incontrôlable en C++, ce qui n'est pas vraiment dans l'esprit du langage. D'ailleurs, cela interagirait très mal avec le concept de tous les objets sont des objets (bien que moi non plus je ne soit pas le plus grand fan de cette fonctionnalité).

Par contre, D gère aussi les interfaces.

[_skip]

En quoi le C++ n'est-il pas tourné vers le Web ?
C'est plus un problème de bibliothèque que de langage, non ?

A part deux ou trois librairies CGI il faut bien reconnaître que le C++ n'offre pas grand chose dans le développement web si on le compare par exemple à Java ou .Net qui proposent des frameworks à base de composants gérant la majeure partie des problèmes liés au session et à AJAX.

Est-ce que c'est juste une histoire de biliothèque? Pas à 100% car la majorité des frameworks de présentation à base de MVC utilisent la réflexion qui n'est pas facilement disponible en C++, je dis pas qu'il est impossible de s'y prendre autrement mais c'est un élément, tout comme la capacité d'un serveur d'application écrit en java à charger dynamiquement, de façon sûre et aisée une autre application java pour servir des requêtes sans laisser les éventuels fautes de celle-ci le faire tomber.

Je dirai qu'en général, le C++ n'était pas vraiment idéal pour tout ce qui est application de gestion en fait, vous connaissez beaucoup d'ORM digne de ce nom en c++? Non? Peut être encore une fois l'absence de la réflexion dans le langage?

Sinon au sujet de D, je partage un peu certains des avis énoncés sur ce topic: son grand point faible est qu'il n'est pas suffisamment utilisé dans le monde professionnel, en conséquence côté communauté et ressources sur le web c'est assez pauvre, et à ce titre je suppose que n'importe qui serait frileux à l'idée de faire confiance à D pour des projets sérieux.

C'est dommage je trouve car une place existe pour un langage tel que D, et je pense que cette place est justement entre C#/Java et C++. Les technos managées sont très productives mais souffrent parfois d'un manque lorsque le développeur souhaiterait pouvoir contrôler très finement la mémoire et que la vitesse d'exécution est une priorité. Le C++, langage compilé, permet ce contrôle fin mais au prix d'un coût en sécurité et en productivité qui est quand même, à mon sens, réel.
Et je perçois le D comme une tentative de donner à un développeur le choix de ce qui est le plus pertinent dans les différentes parties de son projet, par exemple en choisissant d'utiliser le garbage collector pour des parties non critiques et de le désactiver pour les fonctionnalités où la vitesse est primordiale.

En résumé sa meilleure chance serait qu'un grand comme microsoft ou google le *porte*. En l'état actuel j'ai l'impression que ça stagne depuis quelques années.

[MenshaKaine]

Moi ce qui m'étonne c'est que je retombe encore sur un topic sur l'avenir du C++ ...

j'ai l'impression que beaucoup de personne se pose des questions sur ce sujet !

je me demande bien pourquoi ?

[deadalnix]

Il est normal de se poser des question sur ce sujet. C++ à de très vielles bases (le C) qui n'ont plus rien a voir avec le C++ actuel.

Il est normal de vouloir remettre les choses à plat à un moment donné. Je pense que ce moment est venu, car on a bien tiré sur la ficelle du C pour donner C++, ça a eu ses avantages, mais c'est plus un poids que l'on doit trainer qu'un avantage maintenant.

De plus, les langage moderne (C#, Java, voir d'autres comme PHP, Python) n'ont pas les capacités pour remplacer C++ dans bien des cas.

D souffre de défauts de jeunesse, C++ de vieillesse. On est bien loin de la mort de C++ que certains aiment prophétiser, mais je crois que D est tout à fait adapté pour un projet ne réutilisant pas du code C++ en masse, mais pour lequel on aurait typiquement choisis C++.

[Emmanuel Deloget]

A part deux ou trois librairies CGI il faut bien reconnaître que le C++ n'offre pas grand chose dans le développement web si on le compare par exemple à Java ou .Net qui proposent des frameworks à base de composants gérant la majeure partie des problèmes liés au session et à AJAX.

Est-ce que c'est juste une histoire de biliothèque? Pas à 100% car la majorité des frameworks de présentation à base de MVC utilisent la réflexion qui n'est pas facilement disponible en C++, je dis pas qu'il est impossible de s'y prendre autrement mais c'est un élément, tout comme la capacité d'un serveur d'application écrit en java à charger dynamiquement, de façon sûre et aisée une autre application java pour servir des requêtes sans laisser les éventuels fautes de celle-ci le faire tomber.

Je dirai qu'en général, le C++ n'était pas vraiment idéal pour tout ce qui est application de gestion en fait, vous connaissez beaucoup d'ORM digne de ce nom en c++? Non? Peut être encore une fois l'absence de la réflexion dans le langage?

Sinon au sujet de D, je partage un peu certains des avis énoncés sur ce topic: son grand point faible est qu'il n'est pas suffisamment utilisé dans le monde professionnel, en conséquence côté communauté et ressources sur le web c'est assez pauvre, et à ce titre je suppose que n'importe qui serait frileux à l'idée de faire confiance à D pour des projets sérieux.

C'est dommage je trouve car une place existe pour un langage tel que D, et je pense que cette place est justement entre C#/Java et C++. Les technos managées sont très productives mais souffrent parfois d'un manque lorsque le développeur souhaiterait pouvoir contrôler très finement la mémoire et que la vitesse d'exécution est une priorité. Le C++, langage compilé, permet ce contrôle fin mais au prix d'un coût en sécurité et en productivité qui est quand même, à mon sens, réel.
Et je perçois le D comme une tentative de donner à un développeur le choix de ce qui est le plus pertinent dans les différentes parties de son projet, par exemple en choisissant d'utiliser le garbage collector pour des parties non critiques et de le désactiver pour les fonctionnalités où la vitesse est primordiale.

En résumé sa meilleure chance serait qu'un grand comme microsoft ou google le *porte*. En l'état actuel j'ai l'impression que ça stagne depuis quelques années.

Bon, ça n'est pas très lié au sujet de discussion, mais ca mérite reflexion (sans faire de mauvais jeux de mot). Est-ce qu'un Gentil Moderateur pourrait forker la discussion, sous un titre équivoque (C++ et Web) ? Ca me plairait beaucoup de participer à une discussion sur ce sujet.

Concernant le langage D, j'en entend parler depuis si longtemps que si ce langage avait ne serait-ce qu'une petite chance de s'imposer, ça serait déjà fait.

Bon, ce n'est pas le cas - pour plusieurs raisons. La première, c'est le manque de standardisation. Celle-ci aurait du intervenir tôt dans le processus, Digital Mars n'ayant pas la puissance de Sun ou Microsoft pour amener les gens à utiliser ses solutions. Sans standard, il n'y a pas de visibilité sur l'avenir, et les entreprises (qui pourraient être intéressées pour utiliser D) n'aime pas être dans le flou - surtout sur des développements informatiques, qui sont quand même bien souvent critiques. Sans standard, il n'y a aussi pas d'étude des cas aux limites possible.

La seconde, c'est que D réponds à un problème qui ne se pose plus. Sans parler de différences syntaxiques ou de set de fonctionnalités, qu'est-ce qui pourrait différencier D de C++ ? Du point de vue industriel, la seule réponse valide est "les cas d'utilisation". Si D avait des cas d'utilisation précis qui ne pourraient pas être rempli par l'utilisation du C++, de Java ou de C#, alors D aurait un avenir. Si l'utilisation de D pour résoudre un problème P permettait de gagner du temps (disons un facteur 2 ; un gain de temps inférieur à ça n'a pas vraiment d'intérêt, quand on prends en compte les problèmes posés par l'utilisation d'un langage relativement rare dans le cadre de la maintenance et des évolutions à venir) par rapport à l'utilisation d'un langage concurrent ayant les même fonctionnalités, alors D aurait une petite chance d'être utilisée. Mais ce n'est pas le cas. D réponds aux même problèmes que le C++, avec une syntaxe différente. L'intérêt est donc relativement mineur. z

Est-ce que ça peut changer ? Bien sûr que oui - mais ça ne sera pas à cause de l'évolution ou de la non-évolution du C++. Ca sera a cause de l'évolution de D (sa standardisation et son domaine d'application).

[3DArchi]

Bon, ça n'est pas très lié au sujet de discussion, mais ca mérite reflexion (sans faire de mauvais jeux de mot). Est-ce qu'un Gentil Moderateur pourrait forker la discussion, sous un titre équivoque (C++ et Web) ? Ca me plairait beaucoup de participer à une discussion sur ce sujet.

C'est fait : Le langage C++ est-il adapté pour le développement WEB ?

[Niark13]

Je programme en D depuis quelques temps et je pense qu'il est bien pour un usage particulier, mais que pour les entreprises, il est urgent d'attendre.

Par contre, c'est curieux qu'il laisse à certain une impression de langage universitaire : il a été fait par un ingénieur, pas par un académicien et est plutôt pragmatique (enfin je trouve).

L'arrivée d'Andrei Alexandrescu aux commandes a tiré le langage vers le haut : D2 n'est pas vraiment le même langage que D1, avec lequel il est d'ailleurs incompatible. Les templates ont encore gagné en puissance et le langage a gagné du coté de la programmation parallèle (consts transitifs par exemple). Mais D2 ne sera terminé qu'en Avril normalement (avec la sortie du livre "The D programming language" d'Andrei Alexandrescu, qui se veut être le K&R de D.

L'absence de compatibilité source avec le C est plutôt un enorme avantage selon moi. Ça permet de proposer un langage moderne sans avoir à supporter un héritage syntaxique lourd en conséquences (d'un point de vue design). Il est toujours possible de se lier à du code C existant.

La gestion des tableaux en D est un véritable bonheur. La syntaxe des templates est claire.

L'absence d'héritage multiple n'est pas vraiment un problème selon moi : le "alias this" permettant la composition sans effort.

http://www.digitalmars.com/d/2.0/class.html#AliasThis

Le problème des deux bibliothèques standard incompatibles est voué à disparaitre. Phobos 2 est beaucoup plus riche maintenant et Tango 2 se greffera par dessus (au lieu de la remplacer). Coté GUI, Qt, SWT et GTK+ disposent de bindings utilisables.

Non, si j'avais un véritable reproche à formuler à D, ça serait plutôt au niveau des outils :
- DMD (le compilateur officiel) et sa toolchain est pas terrible.
- GDC (le compilateur GNU) ne compile que du D1.
- LDC (le compilateur LLVM) ne fonctionne bien que sous UNIX et ne compile que du D1.
- J'ai pas testé le compilateur D for .Net (pas vu d'intérêt).

Alexandrescu a fait des présentations de D2 chez Intel software. Apparement ils sont plutôt interessés, mais je pense qu'ils attendent de voir ce que donnera D2 avant de prendre la décision de supporter ou non le langage.

Wait & see donc.

[dj.motte]

Salut,

Je considère le D comme un C plus abouti, mais pas un C++ plus abouti.

Le but de réduire l'usine à gaz du C++, ne se réduira pas au D.

[metagoto]

que LSP est, à tout le moins, envisagé d'un coté bizarre de la lorgnette, car quel pourrait bien être le point commun (récupéré de Object) entre une classe voiture, une classe chien et une classe pomme

Y a un truc que je n'ai pas compris par rapport au LSP et les hiérarchies basées sur une super classe Objet (que ce soit forcé ou non par le langage lui même). Je ne dis pas que koala01 affirme ce qui va suivre, je profite juste de son post pour rebondir sur ce genre d'argument qu'on rencontre, et qui prétend:

"Les hiérarchies qui s'appuient invariablement sur une base class de type Objet ne respectent pas le LSP."

Or, la def du LSP:

Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.
http://en.wikipedia.org/wiki/Liskov_...tion_principle

Premièrement, selon moi, le LSP concerne avant toute chose les designers et implémenteurs de langages. Soit leurs systèmes de types autorisent le LSP, soit ils ne l'autorisent pas.

Deuxièmement, sans une analyse "behaviorale" d'un programme , on ne peut rien dire quant à une violation du LSP. On ne peut donc rien dire si la seule chose qu'on sait est "tout dérive de Objet".

Me fourvoie-je ?

[dj.motte]

Y a un truc que je n'ai pas compris par rapport au LSP et les hiérarchies basées sur une super classe Objet (que ce soit forcé ou non par le langage lui même). Je ne dis pas que koala01 affirme ce qui va suivre, je profite juste de son post pour rebondir sur ce genre d'argument qu'on rencontre, et qui prétend:

"Les hiérarchies qui s'appuient invariablement sur une base class de type Objet ne respectent pas le LSP."

Or, la def du LSP:


Premièrement, selon moi, le LSP concerne avant toute chose les designers et implémenteurs de langages. Soit leurs systèmes de types autorisent le LSP, soit ils ne l'autorisent pas.

Deuxièmement, sans une analyse "behaviorale" d'un programme , on ne peut rien dire quant à une violation du LSP. On ne peut donc rien dire si la seule chose qu'on sait est "tout dérive de Objet".

Me fourvoie-je ?

Bonjour,

Il ne faut pas se formaliser ainsi. L'imbécile regarde les règles tandis que le futé dispose de la machine.

[Florian Goo]

L'absence d'héritage multiple n'est pas vraiment un problème selon moi : le "alias this" permettant la composition sans effort.

http://www.digitalmars.com/d/2.0/class.html#AliasThis

Très intéressant cet « alias this », l'une des raisons d'être de l'héritage étant la verbosité induite par la composition.
Dommage qu'on ne puisse en faire qu'un seul par classe.

Alexandrescu a fait des présentations de D2 chez Intel software. Apparement ils sont plutôt interessés, mais je pense qu'ils attendent de voir ce que donnera D2 avant de prendre la décision de supporter ou non le langage.

Wait & see donc.

Bien dit.

[Klaim]

Juste en lisant l'exemple, l'alias this m'apparait comme un hack, peut être nécessaire dans le language.