Discussion :

[Syphys]

Bonne journée, vraiment, même si ça va pas vous plaire...

Je pense que je vais pas me faire d'amis mais bon "on en a gros".

J'apprends le C++. Je tape "C++ merde". Je tombe sur un mail de Linus Torvalds... Décidément c'est mon dieu qui m'éclaire toujours quand c'est obscure. (Passionné de linux depuis mon adolescence et je gère mes projets via git...)

J'ai fait cette recherche car tous les principes objets qui étaient naturel se retrouvent englués dans de la merde conceptuelle :
Pas de polymorphisme ou il faut tout simplement tout recoder ou tout avoir bien codé comme par miracle...
( Et comment faire quand on n'est pas en charge d'une classe dont on aurait besoin qu'une de ses fonctions soient virtuelle??)

J'adore les langages suivant : java comme je le disais, javascript, php, lisp et C. J'ai appris ses langages sans aucun ressentit comme celui que j'ai à propos du C++.

J'en suis à me dire que le C++ n'apporte rien au C qui vaille la peine d'être utilisé sans le risque de tout devoir changer un jour ou alors ne pas utiliser l'héritage ce qui reviens au même...

Après, je comprends : il faut pas cracher sur ce qui te nourrit mais je me sentais obligé de faire part de ma déception étant donné que je me faisais une joie d'apprendre le C++...
Mais ce n'est pas pour ça qu'il faut faire preuve de mauvaise foi : il est évident que le C++ a un problème conceptuel. (Comment peut-on penser que c'est un langage modulaire étant donné qu'il faut tout prévoir en tant que modulaire -pour une modularité circonscrite qui plus est-... ce n'est donc pas modulaire...)

Es-ce que ça vous a fait ça à vous aussi? Est-ce que c'est rédhibitoires? J'ai vraiment plus envie de coder en C++... Je vais demander des anti-dépresseurs à mon médecins.

[Matthieu Brucher]

Un gros troll, mais bon...

Ta classe ne permet pas qu'une fonction soit virtuelle ? C'est le cas dans les autres langages statiques aussi, Java le premier (qui s'est d'ailleurs fortement inspiré du C++ tout au long de ses évolutions. Tu es resté à Java 1 ?)

Linus Torvald a ses opinions, d'autres ont les leurs. Le polymorphisme qui est dans le C++ est génial car il est double : dynamique et statique. Le concepteur des classes originelles a le droit de dire que sa classe ne doit pas être dérivée pour généraliser son comportement, c'est peut-être mieux ! Et tu as d'autres manières de modifier un comportement, il y a pleins de patterns pour ça. Mais il faut se sortir les doigts pour apprendre une nouvelle manière de penser qui ne soit pas impérative, mais orientée objet.

[Syphys]

Merci,

Un gros troll, mais bon...

Je sais...

Ta classe ne permet pas qu'une fonction soit virtuelle ? C'est le cas dans les autres langages statiques aussi, Java le premier (qui s'est d'ailleurs fortement inspiré du C++ tout au long de ses évolutions. Tu es resté à Java 1 ?)

Petit troll mais bon... J'explique comment marche java : dans java tu as des interfaces, des classes abstraites et des classes "normales" : tu peux hériter d'une classe "normale" sans y toucher, sans avoir besoin de connaitre son implémentation et tu bénéficies directement du polymorphisme sans avoir à toucher la classe mère.

Le polymorphisme qui est dans le C++ est génial car il est double : dynamique et statique.

Lueur d'espoir : je n'ai pas saisi les avantages d'une telle possibilité.

Mais il faut se sortir les doigts pour apprendre une nouvelle manière de penser qui ne soit pas impérative, mais orientée objet.

Gros troll mais bon...
Je reproche l'implémentation du concept objet en C++ qui n'est pas élégant, bancale. Donc
- soit je change mon schéma mental conceptuel des princeps objet pour inclure l'implémentation à la C++ (en incluant les possibilité supplémentaires du polymorphisme statique... ce qui me semble, pour l'instant, antinomique je dois le dire...)
- soit je fais avec l'implémentation objet bancale du C++ en utilisant les palliatifs tel que certains pattern comme tu l'as écris et m'encombrer avec des préoccupations futiles, effets de bord de la compatibilité avec le C.

[droggo]

Mai,

Je vais résumer : C++ ne te plaît pas ...

... ça ne nous concerne pas vraiment, surtout que tes arguments sont plus ou moins vaseux (inutile de me demander des précisions, je ne vais pas passer ma vie là-dessus).

La solution est particulièrement simple : tu passes à autre chose, par exemple : assembleur, ce qui ne te posera plus de problème avec le polymorphisme, qui sera exactement comme tu le désires, puisque c'est toi qui le fera.

[Syphys]

La solution est particulièrement simple : tu passes à autre chose,

Je te mets en relation avec mon chef car je sais pas trop comment lui dire ça...

[koala01]

Bonne journée, vraiment, même si ça va pas vous plaire...

Je pense que je vais pas me faire d'amis mais bon "on en a gros".

J'apprends le C++. Je tape "C++ merde".

Avec une recherche pareille, il n'y a rien d'étonnant à trouver des avis tranchés

Je tombe sur un mail de Linus Torvalds... Décidément c'est mon dieu qui m'éclaire toujours quand c'est obscure. (Passionné de linux depuis mon adolescence et je gère mes projets via git...)

C'est un type extra, parait il!

Mais il n'empêche que, comme tout un chacun, il peut dire des conneries manifestes :

• Remets peut être se mail dans le contexte (le premier mail du genre qu'il a écrit date de bien avant la première standardisation du langage)
• Linus est très compétent en C, à n'en pas douter, mais il s'accroche à une manière de penser, et c'est son droit, qui ne s'accorde tout simplement pas avec la pensée orientée objets. A partir de là, son avis ne vaut pas plus que celui de n'importe quel clampin qui n'arrive pas à se remettre en question.

J'ai fait cette recherche car tous les principes objets qui étaient naturel se retrouvent englués dans de la merde conceptuelle :

Ah bon

Les principes "naturels" en programmation orientée objets sont au nombre de six, ni plus, ni moins : il y a la loi de demeter et les principes SOLID.

Il faut, effectivement, prendre conscience que ces principes doivent (devraient ) être respectés au pied de la lettre, à moins d'avoir une raison réelle et plus que valable pour y déroger.

Car, tout comme C, C++ part du principe

Belive the developper, even if it is bullshits

Si C++ a le choix entre permettre quelque chose d'utile au développeur et le lui refuser à cause des problèmes qui surviendront immanquablement en cas de mauvaise utilisation, le choix est vite fait : la fonctionnalité est proposée

Si tu as peur de te tirer une balle dans le pied, ou s'il s'avère que tu es au final beaucoup moins compétant que ce que tu ne le croyais à la base en connaissant java, nous ne t'obligerons jamais à passer à C++

Pas de polymorphisme

On ne doit pas avoir le même cours de C++ alors, car C++ fournit, non pas une sorte de polymorphisme, mais bel et bien plusieurs sortes (polymorphisme ad-hoc et polymorphisme d'inclusion)

ou il faut tout simplement tout recoder

Ah, si c'est mal fait, c'est parfois nécessaire

ou tout avoir bien codé comme par miracle...

Où serait le miracle d'avoir codé correctement

Le développement est un art, certes, mais il s'appuie sur des principes éprouvés!

Evidemment, entre la complexité du langage (car, oui, C++ est complexe, bien qu'il ne soit pas compliqué ), et la rigueur qu'il requière quant au respect des principes, il a tendance à très rapidement mettre les incompétences en relief

( Et comment faire quand on n'est pas en charge d'une classe dont on aurait besoin qu'une de ses fonctions soient virtuelle??)

A priori, si une fonction n'est pas virtuelle, c'est qu'elle n'a pas besoin qu'elle le soit.

Et si tu crois vraiment que tu as besoin de la virtualité de cette fonction, il y a de fortes chances pour que tu n'aies pas respecté LSP avec assez de rigueur (notamment en ce qui concerne les règle de la programmation par contrat)

J'adore les langages suivant : java comme je le disais, javascript, php, lisp et C. J'ai appris ses langages sans aucun ressentit comme celui que j'ai à propos du C++.

A part lisp, j'ai appris les mêmes langages que toi, en plus de quelques autres.

Mais jamais je ne me suis trouvé aussi à l'aise qu'en C++, c'est bizarre, hein

En fait, non... Je cherchais un langage qui ne prenne pas le développeur en otage d'une philosophie qui lui aurait été imposée, et qui l'oblige, justement, à s'intéresser de près aux principes et à leur respect, sous peine de se tirer une balle dans le pied.

C++ comble mes attentes à ce niveau là

J'en suis à me dire que le C++ n'apporte rien au C qui vaille la peine d'être utilisé sans le risque de tout devoir changer un jour ou alors ne pas utiliser l'héritage ce qui reviens au même...

Oh, le gros troll poilu!

Commence donc peut etre par t'intéresser aux six principes que j'ai déjà cités (le forum fourmille de discussions dans lesquelles ils sont abordés ) et apprend peut etre à les utiliser avec la rigueur nécessaire (en gros, la même rigueur que celle avec laquelle tu gères tes pointeurs en C).

Ce n'est que quand tu te seras remis un tout petit peu en question que tu pourras réellement envisager d'évoluer en C++

Après, je comprends : il faut pas cracher sur ce qui te nourrit mais je me sentais obligé de faire part de ma déception étant donné que je me faisais une joie d'apprendre le C++...

Une petite question au passage, tu l'apprends au travers de quel tutoriel / cours / bouquin

Le fait est qu'il y a beaucoup de ceux-ci qui suivent une approche "historique", et que ce n'est vraiment plus la manière dont le C++ devrait être abordé à l'heure actuelle.

Et je t'accorde le fait que trouver de bons bouquins / cours / tuto est assez compliqué comparé à la myriade de m..des sans noms que l'on trouve trop facilement.

Mais ce n'est pas pour ça qu'il faut faire preuve de mauvaise foi : il est évident que le C++ a un problème conceptuel.

Ah bon

(Comment peut-on penser que c'est un langage modulaire étant donné qu'il faut tout prévoir en tant que modulaire -pour une modularité circonscrite qui plus est-... ce n'est donc pas modulaire...)

Attends un tout petit peu!!!

Tu as tout ce qu'il faut pour pouvoir envisager n'importe quelle granularité au niveau de la modularité.

Il arrivera, fatalement, que tu te retrouves avec des éléments qui ne pourront pas être réutilisés, parce que trop orientés vers un secteur particulier, mais, autrement, la modularité se porte aussi bien qu'en C, merci

Es-ce que ça vous a fait ça à vous aussi? Est-ce que c'est rédhibitoires? J'ai vraiment plus envie de coder en C++... Je vais demander des anti-dépresseurs à mon médecins.

Tant pis pour toi, tu passes peut etre à coté de l'occasion d'évoluer dans ta conception de manière générale...

Mais bon, c'est ton choix

[koala01]

Petit troll mais bon... J'explique comment marche java : dans java tu as des interfaces, des classes abstraites et des classes "normales" : tu peux hériter d'une classe "normale" sans y toucher, sans avoir besoin de connaitre son implémentation et tu bénéficies directement du polymorphisme sans avoir à toucher la classe mère.

Ce n'est absolument pas différent en C++:

C'est même encore mieux, dans un sens, car tu gardes même le choix de la manière dont tu envisages tes interfaces:

Ou bien, ce sont des interfaces à base de fonctions virtuelles pures (exactement le principe des interface à la java), ou bien tu peux envisager de fournir des interfaces qui fournissent des comportements spécifiques et totalement transversaux, que tu peux utiliser sans avoir à surcharger ta hiérarchie de classes avec des classes template!

Lueur d'espoir : je n'ai pas saisi les avantages d'une telle possibilité.

Bref, tu as lu deux lignes d'un tuto m...dique et tu crois connaitre C++

Gros troll mais bon...
Je reproche l'implémentation du concept objet en C++ qui n'est pas élégant, bancale. Donc

L'implémentation du concept objet en C++ est complexe, à n'en pas douter, mais elle n'est ni bancale ni inélégante.

Au contraire, elle permet énormément de choses que des langages comme java refusent (et qui sont pourtant conceptuellement correctes )

- soit je change mon schéma mental conceptuel des princeps objet pour inclure l'implémentation à la C++ (en incluant les possibilité supplémentaires du polymorphisme statique... ce qui me semble, pour l'instant, antinomique je dois le dire...)

Non, soit tu change ton schéma mental des principes objets, et meme ton développement java en deviendra meilleur

- soit je fais avec l'implémentation objet bancale du C++ en utilisant les palliatifs tel que certains pattern comme tu l'as écris et m'encombrer avec des préoccupations futiles, effets de bord de la compatibilité avec le C.

Soit tu restes avec tes réflexes java, tu n'évolueras jamais, et nous ne pourrons rien pour toi

[Syphys]

Merci,

Une petite question au passage, tu l'apprends au travers de quel tutoriel / cours / bouquin

J'ai appris les bases avec de multiples sources venant d'internet, de collègues et d'amis (je me fais ma propre vision avec le plus de point de vue différents coupler avec des tests -Socrate disait à Aristote de vérifier tout ce qu'il lui enseignait)
Mais quelques points restaient flou : incompétences des personnes qui ont fait les cours? ou mauvaise fois de développeurs C++ les empêchant de toucher du doigts les éléments problématiques...? Les deux?!

J'ai donc acheté "Pour mieux développer avec C++" j'en suis à la moitié. Je vois bien mieux pourquoi certains point restaient obscure et inabordé (volontairement à en croire le pédant dont vous - les développeurs C++ - faites part à remettre en cause mon intellect). Car je n'ai pas choisi la facilité en targuant : "si vous ne voyez pas que ce langage est conceptuellement mauvais c'est que vous êtes de mauvais développeur".
Sans vouloir parler à ça place, je pense que c'est ce qu'a voulu dire Linus.
Et même je pourrais dire que si j'arrive à la même conclusion, indépendamment, que Linus dont l'intelligence n'est pas à remettre en cause c'est qu'il y a quelque chose.

Je n'ai jamais dis que je n'arrivais pas à me remettre en question c'est d'ailleurs pour ça que je vous sollicite. Preuve en est mes postes dans la discussion alors arrêtez d'être agressifs! Je bouscule trop vos certitudes pour que vous réussissiez à vous contenir?

Citation:

ou tout avoir bien codé comme par miracle...

Où serait le miracle d'avoir codé correctement

Je vais ajouter

ou tout avoir bien codé comme par miracle...

pour la nouvelle problématique/évolution inconnue à l'époque du développement initial.

[koala01]

J'ai appris les bases avec de multiples sources venant d'internet, de collègues et d'amis (je me fais ma propre vision avec le plus de point de vue différents coupler avec des tests -Socrate disait à Aristote de vérifier tout ce qu'il lui enseignait)

Le problème des sources internet, c'est qu'il y a quelques "valeurs sures" (cette section, la plupart du temps, le forum en anglais de stackoverflow, quelques personnes qui savent réellement de quoi elles parlent à gauche et à droite que je ne citerai pas de peur d'en oublier ) pour beaucoup de sources dont la qualité varie de "à peine correcte" à purement horrible

Et je ne te parle pas des traductions de l'anglais au français, qui vont parfois jusqu'à dire exactement le contraire de ce que disait le texte original

Mais quelques points restaient flou : incompétences des personnes qui ont fait les cours? ou mauvaise fois de développeurs C++ les empêchant de toucher du doigts les éléments problématiques...? Les deux?!

En fait, il faut savoir que C++ est un langage complexe.

On en apprend la syntaxe en une vingtaine d'heure, mais pour arriver à le maitriser entièrement, il faut le pratiquer de manière intensive et régulière (je le pratique depuis plusieurs années et je n'en ai pas encore fait le tour ).

Ceci dit, il y a assez facilement moyen de se faire une idée générale de la qualité d'un bouquin sur le C++ en cherchant la partie où il commence à aborder les pointeurs.

Un "bon" cours devrait ne les aborder que juste avant de commencer à parler de polymorphisme.

S'il commence à parler des pointeurs, à te conseiller des new et des delete dés les premiers chapitres, tu peux pour ainsi dire le foutre au feu

J'ai donc acheté "Pour mieux développer avec C++" j'en suis à la moitié.

Ouch... Un livre qui date de 2003 et dont la première version datait apparemment de 1999

Je ne l'ai pas lu, donc je peux (j'espère) me tromper.

Mais si la version de 2003 s'est contentée d'adapter les noms des fichiers d'en-tête à la norme (qui venait de sortir à cette époque, si tant est qu'elle soit déjà sortie), mais qu'il a gardé la même approche que celle de la version précédente, je crains que ce livre ne fasse partie de la catégorie dont je parlais plus haut : le broché devrait bruler correctement et donner beaucoup de chaleur

Je vois bien mieux pourquoi certains point restaient obscure et inabordé (volontairement à en croire le pédant dont vous - les développeurs C++ - faites part à remettre en cause mon intellect).

Il n'y a rien de pédant dans ce que j'ai dit.

Tout le monde le reconnait bien volontiers, C++ est un langage particulièrement complexe, ne serait-ce parce qu'il permet l'utilisation de trois paradigmes différents dans un seul et même projet (parfois même dans une seul et même fichier!).

Le meilleur de l'histoire, c'est que ces trois paradigmes s'intègrent parfaitement bien les uns aux autres en C++

De même, tout le monde te le dira : tu n'as aucun des gardes fous dont tu disposes en java, parce que la philosophie du C++ est

1. Que l'on ne paye que pour ce que l'on emploie (une fonction n'est pas virtuelle à la base, par exemple)
2. Que le développeur sait (ou du moins devrait savoir ) ce qu'il fait, et le langage doit le croire sur parole
3. Que si on a le choix entre fournir une possibilité qui risque de poser problème si elle est mal utilisée ou ne pas la fournir, on choisira de la fournir

Car je n'ai pas choisi la facilité en targuant : "si vous ne voyez pas que ce langage est conceptuellement mauvais c'est que vous êtes de mauvais développeur".

Ce qui est vraiment l'approche de quelqu'un qui soit se laisse abuser par les noms célèbres qui ont eu cette réflexion, soit qui est trop pris dans le carcan de ses certitudes personnelles.

C++ est un langage particulièrement fiable (beaucoup plus que C en tous les cas) et particulièrement puissant, qui couvre une très large gamme de besoins: Il permet aussi bien de se rapprocher énormément du matériel en permettant d'inclure directement du code assembleur en cas de besoin, tout comme il permet d'avoir recours à des techniques avancées en terme de programmation générique et / ou orientée objets.

Mais cette puissance a un prix, et le prix à payer est la complexité du langage.

Sans vouloir parler à ça place, je pense que c'est ce qu'a voulu dire Linus.
Et même je pourrais dire que si j'arrive à la même conclusion, indépendamment, que Linus dont l'intelligence n'est pas à remettre en cause c'est qu'il y a quelque chose.

Je ne remets absolument pas son intelligence en cause, je remets sa capacité à se remettre en question en cause

Mon avis personnel est que tu arrives avec tes certitudes "formatées" par l'usage intensif de java.

Ou avec celles formatées par l'usage intensif de C, au choix.

Le fait est que C++, ce n'est ni java, ni C et que ce qui peut passer comme "bonne pratique" dans l'un et l'autre de ces langages passe souvent comme une faute méritant la pendaison (ou à tout le moins la flagellation )en C++

Je n'ai jamais dis que je n'arrivais pas à me remettre en question c'est d'ailleurs pour ça que je vous sollicite. Preuve en est mes postes dans la discussion alors arrêtez d'être agressifs! Je bouscule trop vos certitudes pour que vous réussissiez à vous contenir?

Dans le fond, tu ne bouscules absolument pas mes certitudes.

Mais dans la forme, je n'ai pu m'empêcher d'utiliser un ton strictement identique à celui que tu utilisais dans ta première intervention

Ceci étant dit, je suis, moi aussi, passé par l'apprentissage de plusieurs langages avant de m'intéresser au C++, et je peux t'assurer que, lorsque l’apprentissage des principes de POO est (trop) orienté vers java (ou vers C#) , les principes "perdent toute leur saveur" et que l'on arrive (parfois) à ne même pas en comprendre le bien fondé.

S'il est possible de développer correctement en java ou en C# tout en prenant "quelques libertés" (parfois très larges ) avec les principes de POO, C++ ne fait que nous "obliger" à aborder ces principes de manière beaucoup plus rigoureuse, du moins, si on veut obtenir un résultat cohérent, maintenable et correct.

Je vais ajouter pour la nouvelle problématique/évolution inconnue à l'époque du développement initial.

Si la conception était vraiment bonne, tu ne devrais pas casser d'avantage pour introduire cette évolution que ce que tu ne devrais casser en java.

Le problème est que les erreurs de conceptions sont fréquentes et que C++ offre, effectivement, une moins bonne tolérance à ce sujet que java

[JolyLoic]

Je veux bien discuter avec toi des points précis qui te semblent poser problème en C++, afin de voir si :
- Ils posent vraiment problème (et il y en a)
- Ils résultent d'une mauvaise compréhension de ta part (étant donné la méthode d'apprentissage que tu indiques, un peu décousue, c'est possible)
- Ils résultent d'un choix de design que tu aurais aimé différent (par exemple, dans une certaine mesure, performances et sécurité d'utilisation sont antinomiques, et le C++ privilégie les performances dans ce cas, alors que d'autres langage s'adressant à d'autres usages privilégieraient la sécurité). (*)

Mais actuellement dans tes posts je vois plus des généralités ou des ébauches de points techniques mais qui ne vont pas assez loin pour vraiment démarrer la discussion (**).

Pas de polymorphisme ou il faut tout simplement tout recoder ou tout avoir bien codé comme par miracle...
( Et comment faire quand on n'est pas en charge d'une classe dont on aurait besoin qu'une de ses fonctions soient virtuelle??)

Si je comprends bien, tu fais allusion au fait qu'en Java les fonctions sont virtuelles par défaut, alors qu'en C++ (comme dans d'autres langages comme par exemple C#), elles ne le sont pas.

Je considère pour ma part que d'un point de vue conception, c'est une bonne chose qu'une fonction soit non virtuelle par défaut. Quand on conçoit une fonction non virtuelle, il suffit d'avoir bien en tête ce que fait la fonction, ses entrées et sorties. Quand on conçoit une fonction virtuelle, il faut en plus documenter dans quels contextes il est possible qu'elle soit appelée. C'est beaucoup plus contraignant et nuit à l'évolutivité d'une classe.

Quand je défini une classe avec 10 fonctions dont 2 virtuelles, j'indique clairement à l'utilisateur : Voici les points de variabilité prévus dans ma classe, et je peux faire évoluer le reste de celle-ci tant que je respecte le contrat étendu de ces deux fonctions virtuelles. Si mes 10 fonctions étaient virtuelles, l'utilisateur croirait qu'il peut tout changer, mais en pratique, ce n'est pas vrai, car le code n'est pas prévu pour.

Il y a même un pattern de développement en C++ que je suis régulièrement et donc je vois régulièrement les bénéfices, qui dit qu'une fonction virtuelle doit être privée, afin de mieux séparer l'interface d'une classe destinée à son utilisateur de celle destinée à qui va en dériver (et de permettre de mettre de l’instrumentation entre les deux).
Il ne nomme NVI : non virtual interface.

J'explique comment marche java : dans java tu as des interfaces, des classes abstraites et des classes "normales" : tu peux hériter d'une classe "normale" sans y toucher, sans avoir besoin de connaitre son implémentation et tu bénéficies directement du polymorphisme sans avoir à toucher la classe mère.

En C++, tu as des classes qui sont abstraites ou pas. Ce que Java nomme une interface n'est qu'un cas particulier d'une classe abstraite (qui n'aurait pas de donnée membre). Tu peux hériter d'une ou plusieurs classes, abstraites ou pas. Et tu n'as pas besoin pour ça de connaître leur implémentation, ni de les modifier. Je ne vois pas là de grosses différences avec le Java (sauf la possibilité d'héritage multiple qui manque en Java, même si Java 8 réintroduit la partie de l'héritage multiple qui lui manque le plus).

Est-ce que tu peux préciser ta pensée ?


(*) Quand j'ai un peu regardé Java, je n'arrêtais pas de me dire "mais, ce langage est totalement tordu et est hyper mal conçu". Puis j'ai lu le livre Effective Java qui m'a montré les principes qui président à la conception de ce langage et qui sont différents des principes du C++. Et alors, je me suis mis à mieux comprendre pourquoi le Java est tel qu'il est. Je ne vais pas dire que j'aime Java, car ses principes de conceptions sont plus éloignés de mon système de valeur que les principes du C++, mais au moins, je peux avoir un certain respect pour ce langage.

(**) et dans le mail de Linus, je ne vois absolument aucun point technique qui puisse amorcer une discussion.

[kremvax]

Juste un petit détail sur ce point qui semble t'agacer particulierement :

( Et comment faire quand on n'est pas en charge d'une classe dont on aurait besoin qu'une de ses fonctions soient virtuelle??)

Il n'y a presque aucune différence avec java sur ce point, si ce n'est la comportement par défaut : en terminologie java on dirait qu'une méthode C++ est finale par défaut. Donc tu aurais pu avoir exactement le même problème avec du code java et des méthodes finales que tu aurais souhaité surcharger.

[Syphys]

Merci beaucoup la discussion prend vraiment une tournure intéressante pour moi et commence à organiser la logique dans ma tête.

Certaines fonctionnalités ont un comportement par défaut différent qu'avec java qui me semblaient naturel auxquels je n'avais plus besoin de réfléchir. Mais ça reste de la convention et pas un concept mal formulé.

Cela engendre le fait les patterns ne changent pas complétement mais s'adaptent au comportement par défaut en plus des nouvelles possibilités.

Il faut le prévoir mais c'est juste un systématisme à réacquérir en C++ que je n'ai pas encore.

En plus il y a quelques éléments dont vous avez parlé que je ne connais pas notamment le pattern NVI qui vont me faire passer un bon dimanche.

Merci encore d'avoir pris le temps de m'expliquer malgré l'intrusion mon exaspération de voir mon intellect insidieusement remis en question.

[Matthieu Brucher]

Petit troll mais bon... J'explique comment marche java : dans java tu as des interfaces, des classes abstraites et des classes "normales" : tu peux hériter d'une classe "normale" sans y toucher, sans avoir besoin de connaitre son implémentation et tu bénéficies directement du polymorphisme sans avoir à toucher la classe mère.

Faux. Contrairement au C++ où tu es virtuel en opt-in, en Java, c'est opt-out, et les bonnes pratiques indiquent de mettre des final là où il faut. La virtualité a un coût non négligeable en place et en efficacité. Ne pas mettre de virtual est un choix délibéré, tout comme mettre des final en Java l'est.
Si tu as souvent bossé avec des classes Java qui ne sont pas final, c'est que tua s eu du code ancien ou mal conçu.

[koala01]

En fait, toutes les différences qui peuvent exister entre C++ et java découlent d'un seule et unique différence:

Java considère que tout est Object. C'est une optique comme une autre qui prend tout son sens en java de par l'utilisation d'une machine virtuelle.

Le fait qu'il puisse exister une classe qui servira, de manière implicite, de base à n'importe quelle autre classe, que ce soit de manière directe ou indirecte, permet de simplifier énormément les choses au niveau de la machine virtuelle : elle peut recevoir strictement tout et n'importe quoi sous la forme d'un pointeur sur Object.

A partir de là, les décisions s'enchainent de manière plus ou moins logique : S'il y a une classe de base commune à toutes celles qui seront créées par l'utilisateur, et que l'utilisateur décide d'utiliser l'héritage multiple par exemple, on se retrouvera dans un héritage en losange, avec les problèmes que cela peut occasionner, donc, on interdit (a priori, à juste titre) l'héritage multiple.

Oui, mais cela pose problème si l'utilisateur souhaite étendre les fonctionnalités d'une de ses classes en y ajoutant celles qui sont définies par une interface!.

Du coup, on fait une distinction entre une classe et une interface, alors qu'une interface n'est jamais qu'une classe qui ne dispose, à la base, que de fonctions virutelles pures et d'aucune donnée.

Et pour bien enfoncer le clou, on crée le mot clé inherits qui implique l'héritage public et le mot clé implements qui implique de travailler avec des interfaces. Or, ces deux mots clé ne sont jamais que les deux faces d'une même pièce : le mécanisme mis en oeuvre au travers de ces deux mots clé est strictement identique car il s'agit du concept d'héritage public, au sens du principe de substitution de Liskov.

De la même manière, les fonctions sont, par défaut virtuelles, selon le principe que l'utilisateur peut toujours vouloir spécialiser un comportement, et qu'il sera beaucoup plus facile de permettre cette spécialisation au niveau de la machine virtuelle si la virtualité fait partie des "propriétés par défaut" des fonctions.

C++ a une approche totalement différente.

D'abord, il ne base pas l'exécution des programmes sur une machine virtuelle: le code généré n'est pas un byte-code qui aura besoin d'être interprété avant d'être envoyé au processeur, mais bel et bien du code que le processeur sera directement en mesure de comprendre.

On n'a donc aucun besoin d'avoir une classe qui serve implicitement de classe à toutes les autres, et l'on n'a aucun besoin d'avoir des fonctions virtuelles de manière systématique, parce que la virtualité d'une fonction, ca a un prix en terme de performances.

Et, à partir de là, les dernières différences sont essentiellement "idéologiques" (on croit le développeur sur parole, même s'il fait des conneries) ou une question de point de vue :

L'héritage multiple est autorisé (car on estime que le développeur sait ce qu'il fait) et il est possible de définir un héritage virtuel (pour éviter les problèmes lorsque deux classe de base ont le même ancêtre).

De même, C++ ne crée aucune distinction "artificielle" entre une classe et une interface : Si le développeur a besoin de quelque chose qui se rapproche du concept d'interface en java, il est totalement libre de créer une classe qui ne dispose d'aucune donnée propre et qui n'expose que des fonctions virtuelles pures

Mais, du coup, on n'a absolument pas besoin de la distinction (tout aussi "artificielle") apportée par les mots clé inherits et implements de java, vu que le mécanisme mis en oeuvre par ces deux mots s'apparente au respect du LSP : Tout ce qu'il nous faut, c'est la possibilité de préciser un (ou plusieurs) héritage(s) public(s) (éventuellement virtuel si besoin).

Et le tout, c'est sans compter sur le fait que java n'a, à la base, qu'une approche strictement orientée objets. Java a beau avoir introduit le concept de Generics, ce ne sont toujours que des classes à la base conçues selon le paradigme OO qui permettent d'accepter différents type (conçus selon le paradigme OO) plus facilement qu'au travers d'un héritage quelconque.

De son coté, C++ apporte une intégration "native" (dans le sens où elle est indépendante de tout le reste) des paradigmes impératif et générique :

Il permet (chose que ne permet pas java) de créer tout aussi bien des fonctions libres "classiques" que des fonctions libres génériques, que des classes "habituelles" (au sens OO du terme), ou des classes générique, et permet "toutes les variations possibles" au sujet de ces différents paradigmes (tu peux très bien avoir une classe générique qui hérite d'une classe "OO" que l'inverse, ou avoir une classe "OO" qui expose une fonction membre générique ou une classe générique qui expose une fonction elle-même générique, et ainsi de suite).

Note au passage qu'il est d'ailleurs tout à fait possible d'envisager de créer des "interfaces" d'un tout autre style en C++ : des interfaces qui disposent de tout ce qu'il faut pour fournir une implémentation cohérente des comportements que l'on attend de leur part, pour des comportements tout à fait orthogonaux, mais qui n'auront pas comme résultat de "surcharger" une hiérarchie de classes ou (pire encore) de relier deux hiérarchies de classes par des relations aussi fortes que l'héritage.

Je veux parler ici des classes génériques (template) telles qu'il est possible d'en créer en C++ .

Alors, évidemment, tout cela mis bout à bout peut parfaitement en dérouter quelques uns qui seraient trop "formatés" par l'approche du paradigme OO de java.

Bien sur, tout cela mis bout à bout fait de C++ un langage particulièrement complexe à appréhender dans son ensemble.

Mais c'est tout cela qui, mis bout à bout, fait de C++ l'un des langages les plus puissants de sa catégorie, même si je t'accorde volontiers le fait que c'est aussi l'un des langages avec lequel il est le plus facile de se "tirer une balle dans le pied" si l"on ne sait pas exactement ce que l'on fait

Pour conclure, on pourrait vraiment dire que les différences entre java et C++ ne sont que le résultat d'une philosophie, de certaines décisions conceptuelles qui ont été prises à la base, qui font que les différents principes (OO, pour rester à ce qui est commun aux deux langages) sont appliqués et mis en oeuvre de manière différente.

Mais cela n'en fait pas de mauvais langages pour la cause, cela en fait juste des langages... différents, qui nécessitent d'envisager les choses sous un angle différent.

Mais le fait de devoir écrire explicitement le mot clé virtual devant une fonction ne veut absolument pas dire que le C++ casse le paradigme OO! Cela veut juste dire que C++ estime que les fonctions membres peuvent parfaitement ne pas être virtuelles si l'on n'a pas besoin qu'elles le soient, et qu'il faut donc indiquer explicitement qu'on souhaite qu'elles le soient .

Au final:

• C++ tend à conscientiser beaucoup plus le développeur des choix conceptuels qu'il fera, à cause essentiellement de sa complexité.
• C++ nécessite d'avoir une approche totalement différente de celle que l'on peut avoir en java.
• C++ est un langage complexe (mais pas compliqué )
• C++ implique de savoir exactement ce que l'on fait et d'avoir de bonnes raisons pour déroger au principes (qui sont les mêmes qu'en java, bien qu'il soit moins risqué d'y déroger en java )

Du coup, tout ce qu'il faut vraiment arriver à faire, c'est d'accepter ces différences et d'accepter le fait que l'approche OO que tu as au travers de ton expérience en java n'est qu'une approche possible, mais que ce n'est ni la seule ni forcément la meilleure.

Si tu acceptes l'idée de revoir ton approche OO afin qu'elle s'accorde avec la "philosophie" C++, tu feras un très grand pas en direction d'une meilleure compréhension de ce langage.

C'est grâce à cette meilleure compréhension du langage que tu pourras évoluer "sereinement" en terme de développement en C++.

Et au final, l'expérience et la "tournure d'esprit" que tu auras acquises en C++ te seront de toutes façons profitables dans n'importe quel langage plus "sécurisant" car tu te seras habitué à envisager les différents concepts et autres principes sans qu'ils ne soient déformés par les restrictions imposées par d'autres langages

[Arzar]

Je ne vois pas là de grosses différences avec le Java (sauf la possibilité d'héritage multiple qui manque en Java, même si Java 8 réintroduit la partie de l'héritage multiple qui lui manque le plus).

Alors ça c'est amusant !
Java 8 propose en effet une nouveauté : les méthodes par défaut dans les interface.
J'aime beaucoup l'ironie, vu qu'on tanne sans cesse le C++ pour sa "merde conceptuelle", pensez-vous donc, ce langage pourri qui permet de faire des horreurs comme fournir une implémentation à une fonction virtuelle pure !
Et voilà que java, quasiment 15 ans plus tard réalise que finalement ce n'est peut être pas une si mauvais idée après tout

[kremvax]

Alors ça c'est amusant !
Java 8 propose en effet une nouveauté : les méthodes par défaut dans les interface.
J'aime beaucoup l'ironie, vu qu'on tanne sans cesse le C++ pour sa "merde conceptuelle", pensez-vous donc, ce langage pourri qui permet de faire des horreurs comme fournir une implémentation à une fonction virtuelle pure !
Et voilà que java, quasiment 15 ans plus tard réalise que finalement ce n'est peut être pas une si mauvais idée après tout

Les guerres de chapelles ont beau lieu d'exister, pour chaque langage on finit toujours par prendre conscience qu'il manque deux ou trois trucs, qu'on finit par intégrer dans le langage. Ca vaut pour java (comme tu dis les impl. par défaut, l'introduction des lambdas etc) mais aussi pour C++ (idem avec les lambdas sur c++11, l'opérateur ":" pour les itérations pioché chez java, etc.)

La "merde conceptuelle" existe chez tout le monde, pas de jaloux

[Luc Hermitte]

Je vais essayer de réagir sur les principaux points techniques qui méritent réponse (comme le dit Loic, l'histoire avec Linus n'a rien de technique, et cela a déjà été discuté)

a- Du virtuel par défaut
Je réjoinds totalement Loic sur ce point. Beaucoup en C++ parleront de vitesse d'exécution qui est impactée par le choix du virtuel par défaut. C'est d'ailleurs un des arguments d'un des deux articles sur le sujet sur artima.
Mais la véritable chose à retenir, c'est le bien fondé des points de variation. Quand un point de variation n'a pas été indubitablement établi, déguiser une fonction en point de variation (en la rendant virtuelle), ça marche pas. Il faudra à un moment ou un autre passer par du refactoring.

Dans les sujets connexes, on peut voir les dégâts de cette approche non maitrisée du polymorphisme dans les premières versions de la lib standard du Java où les listes triées dérivaient des listes ... Ce qui est un des exemples les plus faciles à comprendre de rupture de LSP.

Quand aux interfaces, le C++ a bien mieux en natif avec le pattern NVI. L'autre avantage du pattern, celui pour lequel on l'utilise souvent, c'est pour disposer (en natif) de programmation par contrat. Pour faire de la PpC en Java, il faut passer par des préprocesseurs externes.


b- C ou C++
Pour croire que le C++ n'apporte rien au C, c'est pour moi un indice que l'on programme au pays magique où les erreurs n'existent pas et ne sont pas traitées. Quand il faut écrire des programmes robustes, c'est le jour et la nuit entre le C et le C++. Le C exige un test toutes les deux lignes, et souvent des goto pour forcer du SESE afin de nettoyer nos ressources quand on a fini avec. Plus des variables pour faire remonter la nature des erreurs. Bref, cf le billet de Raymond Chen sur comment reconnaitre des codes incorrects.
Le C++ offre des exceptions (qui sont le mécanisme par défaut pour signaler les exhaustions de mémoire), et le RAII.
Le RAII est la plus grosse différence entre le C et le C++.
[Et là, cf le billet d'Aaron Lahman en réponse au billet de R.Chen, qui a été traduit sur dvpz -> http://alexandre-laurent.developpez....u-exceptions/]

La seconde grosse différence, c'est la bibliothèque standard générique du C++. Et oui, on peut coder en procédural en C++, et pourtant disposer de types et fonctions génériques et intercepter plus proprement les erreurs de typages à la compilation (si on compare l'équivalent macros du C).

c- Au sujet des DP
Je les vois de plus en plus comme des palliatifs aux manques d'un langage. C'est pour cela que je vois le pattern Command comme un contournement à l'absence de support pour la programmation fonctionnelle (il faut lire que le C++ se passe assez bien du pattern Command).
Le pattern Visitor est un palliatif au non support des multi-methods (ou du moins uniquement en arité 2).

d- Je ne suis pas d'accord pour dire que tout est objet en Java.
Les types primitifs en sont un exemple. Et cela a conduit à une multiplication d'implémentation de certains mêmes algorithmes suivant que l'on manipule des tableaux natifs ou des containers. Le paradigme générique offre une factorisation bien plus élégante que ce que l'on trouve en Java.
Par rapport à l'OO, Java a des œillères. Parce que l'on ne peut pas définir des fonctions libres, il fait croire à beaucoup qu'il n'est que OO. Il est facile de faire du non-OO (fonctions statiques à tout va), et limite c'est parfois encouragé de faire du non OO (cf les setters qui maintiennent dans le l'orienté données et non dans l'orienté services). Et en plus il est loin de couvrir tout le paradigme OO (il lui manque des trucs p/r à Eiffel ou Ruby). Mais heureusement, avec l'âge ses mainteneurs voient l'intérêt de lui apporter d'autres paradigmes (généricité, fonctionnel, ...)

[Jean-Marc.Bourguet]

Le pattern Visitor est un palliatif au non support des multi-methods (ou du moins uniquement en arité 2).

Là je ne suis pas d'accord ;-) Le pattern Visitor ayant besoin de multi-méthodes et aucun des 2 langages utilisés dans leur bouquin n'en disposant, la bande de 4 a expliqué une technique pour faire du double dispatch dans les langages n'en disposant pas en complément de leur explication du pattern, technique qui a ses insuffisances mais convient bien aux besoins du pattern. Par la suite, cette technique est la seule chose que certains ont retenu du pattern.

[Astraya]

Bonjour,

Je reviens sur le premier post (Désolé de ne pas lire tes romans Koala ).

Ce que je comprends, tu aimes le C mais pas le C++. Pourtant le C++ apporte ce qu'il manque au C, l'orienté objet. Java l'est! Bien alors qu'elle différence entre Java et C++? pour moi la première est la gestion de la mémoire. Alors on peut dire ce que l'on veut, tu peux en C++ faire exactement ce que fait Java. Sauf que C++ te permet de pas le faire.
Dire que C++ c'est la merde et bien c'est tout simplement avouer ton découragement à l'apprentissage d'un langage qui te permets de TOUT faire et de bien le faire, mais avec une courbe d'apprentissage plus complexe!

Donc non C++ n'est pas un langage de merde, C++ est un langage puissant, complexe et rapide qui te permet de tout faire, IHM(Qt), embarqué, jeu vidéo, médical, robotique, téléphonie....

Ne crache pas sur ce langage parce que tu ne le comprends pas. Persévère et comme beaucoup lorsque tu partiras du C++ vers un autre langage tu auras beaucoup de mal (Même si ce langage est plus "simple") car tu auras l'habitude de réfléchir autrement.

[r0d]

Moi il y a une chose que je reproche a c++ par rapport à d'autres langages comme le c# ou le java, c'est l'édition de lien, et la gestion des dépendances en général.
J'avoue que je n'y comprend rien, c'est donc certainement pour ça que ça m'énerve. Mais la gestion des dépendances en c++ est un véritable purgatoire pour moi. Il suffit qu'on change une chose dans le contexte de dev (version du compilateur, O.S, une option de compilation, une nouvelle dépendance, parfois même le type de processeur, etc.) et c'est parti pour des heures de prises de tête avec l'édition des liens, de recompilation des dépendances etc.
Dans les deux autres langages que je connais relativement bien, c# et java, ces problèmes n'existent pas. Et je ne parle pas des dépendances aux frameworks, mais bel et bien de dépendances entre divers modules, soit que nous avons développé nous-même, soit des lib open source récupérées sur le net.
Là par exemple, je suis sur un gros projet de 200.000 lignes de code, avec une dizaine de dépendances, et j'essaie de le compiler avec VS 2013, et chaque problème corrigé est plus complexe que le précédent.
Alors au final bien sûr, on y arrive; mais l'effort demandé me parait trop important.