Discussion :

[Alp]

J'aurais tendance à être d'accord mais comme on travaille rarement seul, et que le niveau de chacun est très variable, il est souvent préférable de viser ce qui sera le plus simple et clair pour tout le monde, directement.

Personnellement, c'est comme pour vous, quand j'ai à mettre les mains dans du Java, je galère... C'est une question de point de vue.

JOui mais le fait que les interface soient des classes abstraites pures élimine les cas complexes que peut provoquer l'héritage multiple.

Héritage virtuel => solution.

JCe qui me gène surtout c'est que ça détourne une utilisation existante d'un opérateur pour faire autre chose. En toute logique, un opérateur se devrait de retourner un résultat sans interagir avec autre chose que ces opérandes devrait
Je suis le premier a trouver ça sympathique.

Oui, assez subjectif. J'aurais compris que tu trouves un opérateur comme <<|||||||||******----+++<< peut pratique, mais << ça va je trouve

JJe suis pas un expert C++ loin de la, mais il me semble que comme en C, tant que l'on ne sort pas de l'espace mémoire de l'application il ne se passe rien non?

Tu peux avoir pleins de pépins. Mais quand tu utilises un std::vector ou similaire, tu as une gestion des erreurs (y compris les indices trop grands, ou quoi) avec exceptions, par exemple.

JQuant au pointeurs intelligents, il ont beau exister. A ce que j'ai lu les pointeurs de la STL sont loin d'être suffisants pour gérer tous les problèmes et comme ce n'est pas intégré au langage, c'est loin d'être naturel à utiliser.
Enfin j'ai quand même l'impression que le pointeurs classiques sont toujours utilisés un peu partout.

On fait de notre mieux pour répandre les bonnes pratiques d'aujourd'hui en C++, après c'est aux programmeurs C++ de se former au mieux. Par contre, tout le monde est d'accord ici je pense pour dire (à nouveau) que le C++ donne plus de libertés, mais avec les risques qui viennent avec.

[millie]

Je suis pas un expert C++ loin de la, mais il me semble que comme en C, tant que l'on ne sort pas de l'espace mémoire de l'application il ne se passe rien non?

Pour une application standard dans un OS standard, tu ne peux pas sortir de la mémoire virtuelle à cause de la MMU (hors mode noyau).
L'OS ne fait qu'intercepter l'accès à des adresses virtuelles non légales et te renvois un Segmentation Fault sous UNIX et une boite d'erreur sous Windows.

[adiGuba]

Héritage virtuel => solution.

Non justement... mais c'est encore une fois une différence de philosophie.

A mon avis l'héritage virtuel par défaut apporte vraiment beaucoup à la vision "objet" de Java, et je trouve cela bien plus utile que l'héritage multiple...

a++

[Uther]

Pour une application standard dans un OS standard, tu ne peux pas sortir de la mémoire virtuelle à cause de la MMU (hors mode noyau).
L'OS ne fait qu'intercepter l'accès à des adresses virtuelles non légales et te renvois un Segmentation Fault sous UNIX et une boite d'erreur sous Windows.

On est d'accord mais on peut bien pourrir sa propre application si on a une adresse incorrecte mais légale, non?

Tu peux avoir pleins de pépins. Mais quand tu utilises un std::vector ou similaire, tu as une gestion des erreurs (y compris les indices trop grands, ou quoi) avec exceptions, par exemple.

Je parlais des tableaux/pointeur. Il me semble bien que comme en C, il n'y a pas de contrôle fait dessus, non?

Oui, assez subjectif. J'aurais compris que tu trouves un opérateur comme <<|||||||||******----+++<< peut pratique, mais << ça va je trouve

J'avais posté mon message non terminé par erreur
Ce n'est pas la lisibilité de la chose qui me gène mais le fait que ce n'est pas cohérent avec le fonctionnement normal d'un l'opérateur.
Il me semble qu'en toute logique un opérateur devrait simplement retourner un résultat sans interagir avec autre chose que ces opérandes et rester sans effet de bord (sauf évidement pour les opérateurs d'affectation)

On fait de notre mieux pour répandre les bonnes pratiques d'aujourd'hui en C++, après c'est aux programmeurs C++ de se former au mieux. Par contre, tout le monde est d'accord ici je pense pour dire (à nouveau) que le C++ donne plus de libertés, mais avec les risques qui viennent avec.

Ce que je trouve gênant c'est que les outils pour mettre en œuvre ces bonnes pratiques(comme les pointeurs intelligents) ne fassent pas partie du langage ni même de la bibliothèque standard.
Sur le fait que C++ est plus souple et aussi plus risqué, je pense que tout le monde est d'accord.

[Alp]

Je parlais des tableaux/pointeur. Il me semble bien que comme en C, il n'y a pas de contrôle fait dessus, non?

Si on utilises des pointeurs bruts, non.

J'avais posté mon message non terminé par erreur
Ce n'est pas la lisibilité de la chose qui me gène mais le fait que ce n'est pas cohérent avec le fonctionnement normal d'un l'opérateur.
Il me semble qu'en toute logique un opérateur devrait simplement retourner un résultat sans interagir avec autre chose que ces opérandes et rester sans effet de bord (sauf évidement pour les opérateurs d'affectation)

C'est assez restreint comme vision Question de point de vue encore, même si je comprends tout à fait le tien.

Ce que je trouve gênant c'est que les outils pour mettre en œuvre ces bonnes pratiques(comme les pointeurs intelligents) ne fassent pas partie du langage ni même de la bibliothèque standard.
Sur le fait que C++ est plus souple et aussi plus risqué, je pense que tout le monde est d'accord.

C'est en cours ! C++0x (prochaine version de la norme C++) comprend énormément de nouveautés ! On en parle pas mal côté C++ de DVP si tu veux y jeter un coup d'oeil.
Les grands compilateurs ont déjà intégrés certaines de ces nouveautés d'ailleurs (VC++, GCC, Intel C++).

[gorgonite]

C'est en cours ! C++0x (prochaine version de la norme C++) comprend énormément de nouveautés ! On en parle pas mal côté C++ de DVP si tu veux y jeter un coup d'oeil.
Les grands compilateurs ont déjà intégrés certaines de ces nouveautés d'ailleurs (VC++, GCC, Intel C++).

et comeau ?

[Alp]

Comeau je ne sais pas, pas de version gratuite et pas essayé
Tu l'as ? Il implémente une partie du draft 0x ?

[hegros]

Si il y a un point positif du C++ qui a été perdu(et qui ne sera probablement pas récupéré par la suite) en Java c'est bien la surcharge des opérateurs. En haskell c'est pas trivial à moins d'être du domaine certains opérateurs ne sont pas du tout explicite notamment le $(sans l'explication de Alp quasi impossible de deviner les intentions de code)

Pour l'histoire des pointeurs au dessus c'est un peu fort de café parce qu'en C++ contrairement à JAVA ce n'est pas objet un pointeur ou un tableau du coup les exceptions faut oublier... Peut-être aussi que le compilateur est plus permissif que JAVA sur les indices de tableaux.

Aussi ce qui manque au C++, peut-être un option existe mais pas à ma connaissance, par rapport à JAVA c'est les exceptions obligatoires à traiter signalées par le compilateur.

Quand au bas niveau qu'on reproche au C++ il ne faudrait pas oublier que c'est aussi possible en JAVA...

[Garulfo]

Si il y a un point positif du C++ qui a été perdu(et qui ne sera probablement pas récupéré par la suite) en Java c'est bien la surcharge des opérateurs. En haskell c'est pas trivial à moins d'être du domaine certains opérateurs ne sont pas du tout explicite notamment le $(sans l'explication de Alp quasi impossible de deviner les intentions de code)[...]

Tu n'a pas tort pour Haskell, mais ceci est souvent vrai pour tout opérateur. Ainsi un débutant en C++ n'a aucune chance de deviner les sens de & et de * si on ne lui dit pas. D'autant que ce dernier se confond avec la multiplication. De très nombreux étudiants montrent des difficultés à comprendre que << et >> sont les opérateurs de manipulation de flots et que ce ne sont pas cout ou cin, lorsqu'ils voient la syntaxe pour la première fois. Et que dire de « ?: » ? Bien sûr quand on connait la programmation et qu'on a l'explication ça devient simple.

La surcharge n'a pas que des bons côtés. C'est aisé d'avoir un programme illisible avec des opérateurs surchargés lorsque les choix de ces derniers sont mauvais. La surcharge de [] peut faire des miracles cependant. C'est donc un risque avec des avantages, comme l'arithmétique des pointeurs.

[hegros]

De très nombreux étudiants montrent des difficultés à comprendre que << et >> sont les opérateurs de manipulation de flots et que ce ne sont pas cout ou cin, lorsqu'ils voient la syntaxe pour la première fois. Et que dire de « ?: » ? Bien sûr quand on connait la programmation et qu'on a l'explication ça devient simple.

Tu connais le dicton il n'y a pas de mauvais élèves il n'y a que de mauvais enseignement/enseignant.

De plus je ne reviendrais pas sur ce qui a déjà été dis concernant l'utilisation massive de ces opérateurs de flots c'est depuis longtemps intégré sur les systèmes d'origine unix.

Le ? ce n'est pas un opérateur surchargeable en C++ il me semble de plus c'est déjà intégré depuis le C comme opérateur ternaire( i>0 : quelquechose ? autrechose)

Et effectivement la surcharge a ses +/- quand c'est illisible (comme l'exemple avec haskell) il faut un commentaire c'est tout

[Uther]

De plus je ne reviendrais pas sur ce qui a déjà été dis concernant l'utilisation massive de ces opérateurs de flots c'est depuis longtemps intégré sur les systèmes d'origine unix.

Ce qui est anormal c'est que justement a l'origine il ne s'agit pas d'opérateurs de flot mais d'opérateurs de décalage de bit, dont l'usage est détourné pour les faire ressembler à des opérateurs de flots Unix alors que leur fonctionnement n'a rien a voir.

Vu que c'est un cas courant et intégré à la bibliothèque standard, c'est connu de tous et donc pas vraiment problématique. Mais ce genre de détournement sur un programme lambda n'est a mon avis pas souhaitable.

[koala01]

Ce qui est anormal c'est que justement a l'origine il ne s'agit pas d'opérateurs de flot mais d'opérateurs de décalage de bit, dont l'usage est détourné pour les faire ressembler à des opérateurs de flots.
Vu que c'est un cas courant et intégré à la bibliothèque standard, c'est connu donc pas vraiment problématique, mais ce genre de détournement sur un programme lambda n'est a mon avis pas souhaitable.

Seulement, dire cela, c'est vouloir refaire l'histoire...

On peut, effectivement, estimer à la lumière des nouvelles techniques de conceptions et de langages plus récents, que le choix de << et >> n'était pas *forcément* judicieux.

Mais d'un autre coté, il est vraiment difficile, y compris pour un débutant, de confondre l'opérateur de décalage de bit << ou >> avec l'opérateur de flux similaire...

Le premier va fonctionner avec nombres des deux coté alors que le deuxième va travailler avec un flux à gauche et... n'importe quoi à droite.

Si C++ était moins "typé" qu'il ne l'est, effectivement, le problème pourrait se poser, mais ici, ce n'est pas le cas

[Garulfo]

Tu connais le dicton il n'y a pas de mauvais élèves il n'y a que de mauvais enseignement/enseignant.

De plus je ne reviendrais pas sur ce qui a déjà été dis concernant l'utilisation massive de ces opérateurs de flots c'est depuis longtemps intégré sur les systèmes d'origine unix.

Le ? ce n'est pas un opérateur surchargeable en C++ il me semble de plus c'est déjà intégré depuis le C comme opérateur ternaire( i>0 : quelquechose ? autrechose)

Et effectivement la surcharge a ses +/- quand c'est illisible (comme l'exemple avec haskell) il faut un commentaire c'est tout

Tiens je ne connais pas ce dicton. Ça doit être un truc que se passe les mauvais étudiants pour se rassurer avant de venir dire des âneries sur les forums

Bon blague à part ça je ne parlais pas de surcharge de « ? »... je disais que l'opérateur ternaire « ?: » est illisible pour un débutant. Je ne sais pas ce que tu as compris de mon message, mais il me semble que tu l'as lu de travers ; à moins que je ne me soit mal exprimé. Je disais simplement que tout opérateur est obscur lorsqu'on le voit pour la première fois. La première fois qu'un enfant voit un +, c'est obscur pour lui. Certains ont une sémantique qui se transmet dans plusieurs langages, d'autres non. Le * (pointeur) en C/C++ n'est pas vraiment en rapport avec la multiplication. D'ailleurs Bjarne Stroutrup aurait voulu intégrer le « -> » comme indication d'un pointeur. Mais ça ne s'est jamais fait. Ça aurait été peut-être plus explicite, mais uniquement une fois expliqué par quelqu'un qui connait.

[hegros]

Tiens je ne connais pas ce dicton. Ça doit être un truc que se passe les mauvais étudiants pour se rassurer avant de venir dire des âneries sur les forums

Cela veut dire tout simplement qu'il y a des professeurs qui ne savent pas enseigner, ils créent des mauvais étudiants à l'image de leurs mauvais enseignements c'est tout et c'est valable pour le C++ et le JAVA il n'y a qu'à voir sur le forum d'où le il n'y a que de mauvais professeurs au final

Bon blague à part ça je ne parlais pas de surcharge de « ? »... je disais que l'opérateur ternaire « ?: » est illisible pour un débutant.

Etant débutant je ne me souviens pas avoir trouvé cet opérateur illisible il faut dire que j'avais un bon professeur pour me l'enseigner parce qu'il y en a qui rendent effectivement tout illisible et ambigu dés qu'ils ouvrent leur bouche

On sort du sujet mais effectivement trop de professeurs connaissent très bien leur matière de génie logiciel et de technique mais ne savent que très peu de chose en enseignement hors connaître l'enseignement est plus important que connaître le matière à enseigner lorsqu'on est professeur malheureusement en pratique on rencontre le plus souvent l'inverse

[hegros]

Ce qui est anormal c'est que justement a l'origine il ne s'agit pas d'opérateurs de flot mais d'opérateurs de décalage de bit, dont l'usage est détourné pour les faire ressembler à des opérateurs de flots Unix alors que leur fonctionnement n'a rien a voir.

Rien n'empêche en C++ de surcharger ces opérateurs (<< et >>) pour faire du décalage de bit c'est cela la puissance des opérateurs c'est qu'on leur donne le sens que l'on veut finalement.

En plus vous avez pris un exemple particulier l'objet cout comparez à l'objet out en JAVA qui est son équivalent il y a bien une différence.

En JAVA le principe de l'encapsulation est violé puisqu'on écrit system.out.printl("une chaine") alors qu'en C++ on résouds cela avec la surcharge de l'opérateur << et une fonction ami de ostream et de ce fait on ne viole pas l'encapsulation.

[souviron34]

trop de professeurs connaissent très bien leur matière de génie logiciel et de technique mais ne savent que très peu de chose en enseignement hors connaître l'enseignement est plus important que connaître le matière à enseigner lorsqu'on est professeur malheureusement en pratique on rencontre le plus souvent l'inverse

j'aurais plutôt dit l'inverse, par expérience :

trop de professeurs connaissent très bien leur matière de génie logiciel et de technique mais ne savent que très peu de chose dans l'application réelle de ces techniques or connaître l'application réelle d'une technique est au moins aussi sinon plus important que connaître la technique lorsqu'on est professeur malheureusement en pratique on rencontre le plus souvent l'inverse...




"des têtes bien pleines, mais pas forcément bien faites"....

[hegros]

j'aurais plutôt dit l'inverse, par expérience :

trop de professeurs connaissent très bien leur matière de génie logiciel et de technique mais ne savent que très peu de chose dans l'application réelle de ces techniques or connaître l'application réelle d'une technique est au moins aussi sinon plus important que connaître la technique lorsqu'on est professeur malheureusement en pratique on rencontre le plus souvent l'inverse...




"des têtes bien pleines, mais pas forcément bien faites"....

Oui il y a aussi ce cas là mais je parlais du cas de celui qui est très bon en thèorie et très bon en pratique pour sa matière (le développement logiciel) mais qui ne sait pas l'enseigner. L'enseignement c'est une matière aussi à part qui demande à elle aussi théorie et pratique

[Uther]

Rien n'empêche en C++ de surcharger ces opérateurs (<< et >>) pour faire du décalage de bit c'est cela la puissance des opérateurs c'est qu'on leur donne le sens que l'on veut finalement.

Pour moi quelque chose qui brise la logique naturelle d'un langage est plus "dangeureux" que "puissant"?
Surcharger un opérateur '+' me parait logique entre des objets pour lesquels il fait sens d'avoir une addition (des dates, chaines, ...).
Modifier le sens d'un opérateur en autre chose est au contraire pour moi une mauvaise idée.
Le cas du cout n'est en pratique pas gennant car il fait partie de la lib standard. On l'apprend dès le son premier "Hello World" en C++, même si beaucoup de gens ne se rendent compte qu'il s'agit en fait d'une surcharge que bien plus tard(quand il s'en rendent compte). Mais dans son propre code, si on fait n'importe quoi avec la surcharge, on peut vite arriver a faire du code trompeur.

En JAVA le principe de l'encapsulation est violé puisqu'on écrit system.out.printl("une chaine") alors qu'en C++ on résouds cela avec la surcharge de l'opérateur << et une fonction ami de ostream et de ce fait on ne viole pas l'encapsulation.

Pourais tu expliciter s'il te plait car je ne vois pas vraiment ce que viens faire l'encapsulation la dedans, ni vraiment pourquoi elle serait plus violée par un langage que par l'autre.

[hegros]

Pourais tu expliciter s'il te plait car je ne vois pas vraiment ce que viens faire l'encapsulation la dedans, ni vraiment pourquoi elle serait plus violée par un langage que par l'autre.

Pour afficher une chaîne sur la sortie standard soit une console windows ou unix.

En C++

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

cout << "ma chaine sur la sortie standard";

On a surchargé l"opérateur << de la classe de l'objet cout moyennant une fonction amie.


En Java

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

System.out.println("ma chaine sur la sortie standard");

C'est la méthode println de l'objet out qui doit être appelée qui est un attribut de System accessible de l'extérieur en cela on a brisé un principe élémentaire de la POO à savoir l'encapsulation(out est une donnée membre public).


Vous preniez pour exemple l'objet particulier cout alors qu'en java son équivalent n'est pas mieux cependant comme dis plus haut c'est un cas particulier pour out et pour cout

[Uther]

Cet objet étant déclaré comme static final, il ne peux pas être modifié, même pas par héritage, donc il me semble au contraire très bien encapsulé.