Discussion :

[Jean-Marc.Bourguet]

Comme je l'ai dit la différence est surtout qu'en Java tout est virtuel par défaut à l'inverse du C++...

On peut changer le defaut en Java? Il me semblait que non (en particulier final remplit une partie des besoins mais pas tous en ce qui concerne les membres non virtuels).

Mais de toute manière je pense que ce ne sera jamais le cas car cela ne rentre pas dans la philosophie du langage. D'ailleurs c'est ce qu'on peut lire sur cette RFE concernant l'héritage multiple :

Tout comme il ne devait pas avoir de genericite, ou que les flottants devaient fournir des resultats identiques sur toutes les implementations. Deux choses qui ont ete changees.

Je ne suis pas un grand fan de l'heritage multiple -- surtout que la version restreinte de Java connue sous le nom d'interface remplit la plupart des besoins. Mais c'est uniquement la plupart et la version restreinte l'etait un peu trop a mon gout la derniere fois que j'ai regarde.

[Jean-Marc.Bourguet]

Code :

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

1
2
3
4
5
6
                        Java  C++   Pour                               Contre
Réflexivité               O    N   Exécution et chargement dynmique  Compilation difficile et code plus lent
Héritage multiple         N    O   meilleur factorisation            Code compliqué, ambigu et Contournement possible par délégations
Generics/templates        O    O   Code + modulaire et pas de casts  Compliqué
Garbage collector         O    N   Mémoire mieux gérée               Désallocation plus lente et mal maitrisée

etc.

Deux remarques sur le tableau.
- Generic/template: les modeles de Java et de C++ sont tres differents. Celui de C++ est beaucoup plus puissant -- et la difference de puissance va s'agraver avec C++0X. Celui de Java permet une implementation partagee -- effet qu'il est possible en C++ en codant un peu plus d'une maniere tres stylisee, un cible evidente pour la generation automatique de code si le besoin s'en fait sentir. Ton avantage (code + modulaire et pas de cast) oublie le surcroit de puissance du C++, et l'avantage qui me semble tres important de la verification statique des types. Au fait, en quoi les templates sont compliques?

- GC: je ne suis pas d'accord que la memoire est mieux geree. Le GC c'est diminuer le cout d'implementation en le payant principalement par une plus mauvaise gestion de la memoire occupee. Et si je n'ai rien contre le GC employe a bon escient, il a un risque fort: de faire croire que la gestion de la memoire est automatique (alors qu'il faut continuer a concevoir dans le domaine -- meme si l'implementation est simplifiee) et donc d'utiliser un ownership partage quand ce n'est pas ce qu'il faut.

[adiGuba]

On peut changer le defaut en Java? Il me semblait que non (en particulier final remplit une partie des besoins mais pas tous en ce qui concerne les membres non virtuels).

En effet : si le mot-clef final empêche seulement la méthode d'être redéfini dans une classe fille. Cette limitation est seulement dû à l'absence d'héritage multiple.

Tout comme il ne devait pas avoir de genericite,

La généricité existe dans tout les langages objets

Je rigole je comprend bien que tu parles des Generics ! En fait lorsque tu regardes la RFE correspondante tu vois que dès le début les avis était positif. Et si cela a pris autant de temps c'est surtout parce que l'implémentation devait permettre une compatibilité avec les API et application existante :

Parameterization can indeed be very useful. In considering the various proposals, we are particularly concerned about the impact of such a large change on our customers, especially with respect to compatibility and stability.

C'est pour cela qu'on a des Generics et non pas des Templates

a++

[Jean-Marc.Bourguet]

La généricité existe dans tout les langages objets

C'est encore un de ces mots surcharges. Je l'utilisais dans le sens de polymorphisme parametrique.

Je rigole je comprend bien que tu parles des Generics ! En fait lorsque tu regardes la RFE correspondante tu vois que dès le début les avis était positif.

Je parle de commentaires tres explicites fait vers 1996-1997 par des gens de Sun. J'ai jamais fait serieusement du Java, mais je regarde le langage de plus ou moins loin quasiment depuis qu'il est sorti de Sun. Apparemement il y a eu un changement d'opinion rapide, a moins que tout le monde n'etait pas du meme avis; il n'est pas impossible non plus qu'il y ait eu un aspect marketing dans la presentation.

[deltree]

Deux remarques sur le tableau.
- Generic/template: les modeles de Java et de C++ sont tres differents. Celui de C++ est beaucoup plus puissant -- et la difference de puissance va s'agraver avec C++0X. Celui de Java permet une implementation partagee -- effet qu'il est possible en C++ en codant un peu plus d'une maniere tres stylisee, un cible evidente pour la generation automatique de code si le besoin s'en fait sentir. Ton avantage (code + modulaire et pas de cast) oublie le surcroit de puissance du C++, et l'avantage qui me semble tres important de la verification statique des types. Au fait, en quoi les templates sont compliques?

- GC: je ne suis pas d'accord que la memoire est mieux geree. Le GC c'est diminuer le cout d'implementation en le payant principalement par une plus mauvaise gestion de la memoire occupee. Et si je n'ai rien contre le GC employe a bon escient, il a un risque fort: de faire croire que la gestion de la memoire est automatique (alors qu'il faut continuer a concevoir dans le domaine -- meme si l'implementation est simplifiee) et donc d'utiliser un ownership partage quand ce n'est pas ce qu'il faut.

D'accord, j'ai voulu faire cours car le garbage a déjà été abordé ainsi que les problèmes de générics, et on abordait les problèmes de réflexivité.
Quand tu dit "l'implémentation est simplifiée" c'est une bonne formule pour résumer l'avantage du GC.
Par "pas de cast" je voulais en effet dire vérification statique des types: qu'est-ce qui fait le srucroit de puissance du C++ dans ce cas?

Pour répondre à ta question: les generics sont complexes en Java quand on transmet le type generics d'une classe à l'autre avec des wildcards, exemple sur une méthode max de type collection:

Code :

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

1
2
3
public static <T extends Comparable<? super T>> 
        T max(Collection<T> coll)

http://java.sun.com/docs/books/tutor...s/morefun.html
Outre la syntaxe (beurk) je ne suis pas sûr que les 3/4 des programmeurs s'intéressent vraiment à utiliser les bons wildcards, la plupart vont restreindre la fonction max à un "T extends Comparable<T>"

Si on ajoute à ça des générics à 2 types, par exemple des classes utilisant des Map, on se tire des balles.

[pseudocode]

Outre la syntaxe (beurk) je ne suis pas sûr que les 3/4 des programmeurs s'intéressent vraiment à utiliser les bons wildcards, la plupart vont restreindre la fonction max à un "T extends Comparable<T>"

Si on ajoute à ça des générics à 2 types, par exemple des classes utilisant des Map, on se tire des balles.

Plus ca va, plus la syntaxe de Java commence a devenir complexe. Les generics etaient vraiment indispensables, donc j'accepte la surcharge syntaxique necessaire.

Les Wildcards et les annotations, franchement j'aurais pu m'en passer.

Et quand je vois qu'ils veulent rajouter des "closures" (ou similaires), ca va devenir franchement complexe. On risque de retomber dans les travers du C++: "on peut tout faire... a condition de savoir le faire."

[HanLee]

> Jedai : pour ta réponse d'il y a longtemps : si, je suis de ton avis .

Et quand je vois qu'ils veulent rajouter des "closures" (ou similaires), ca va devenir franchement complexe. On risque de retomber dans les travers du C++: "on peut tout faire... a condition de savoir le faire."

Dans ce cas de figure précis, là je te comprends pas.

Généralement, les choses comme ça qui viennent des langages fonctionnels, c'est bénéfique, en terme d'expressivité et de concision.

Closures, lambda, etc... : tout tourne autour des fonctions, ça permet donc d'exprimer sa pensée plus directement, sans détours et approximations syntaxiques via des classes locales ou anonymes...

Et la syntaxe est quasiment la même que pour des classes ou des fonctions, donc la complexité...

Difficile d'en abuser jusqu'à les dénaturer : les closures, c'est pour quelque chose de local, temporaire, qu'on utilise principalement pour faire sous-traiter une action par quelque chose d'autre.

[pseudocode]

C'est toujours beau, propre et clair sur le papier... et puis arrive la réalité:

vaut il mieux une classe anonyme ou une closure ?
Est ce qu'on peut heriter d'un closure ? l'overloader ? l'overrider ?
Est-ce qu'on peu invoquer une closure par reflection ?

Que fait cette très simple closure ?

Code java :

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

1
2
3
4
5
6
7
public static <T,U> void mystere(Map<T,U> m,
        {T, U=> } block) {
    for (Iterator<T> it = m.keySet().iterator(); it.hasNext(); ) {
        T key = it.next();
        block.invoke(key, m.get(key));
    }
}

Je prefere que Java reste simple... pour la complexité, il reste toujours le C++ !

[HanLee]

C'est toujours beau, propre et clair sur le papier... et puis arrive la réalité:

...

Est ce qu'on peut heriter d'un closure ? l'overloader ? l'overrider ?
Est-ce qu'on peu invoquer une closure par reflection ?

Et pourquoi tu voudrais faire ça ?
L'idée derrière, c'est que closure est une fonction, et non une classe. Est-ce que ça a un sens de vouloir en hériter, la redéfinir ?

Ensuite, est-ce qu'on peut vraiment faire ce à quoi tu penses en Java ?
Si oui alors ce sont pas des belles closures... J'interdirais ça.

---------

Et pour ta fonction, si tu penses qu'elle est déroutante pour les programmeurs, je pense que la difficulté vient juste qu'il faut s'habituer à manipuler des "first-class functions", ce que les Java-men ne font pas souvent à cause du langage.

Mais on le fait tout le temps quand on veut trier quelque chose, quand on veut faire des callbacks en C, etc. !

Si on a manipulé un peu de maths élémentaires dans sa vie (théorie des ensembles + fonctions, c'est tout), alors on sait faire l'amalgame immédiatement !

Donc en prenant ton exemple, on comprendrait vite que ta fonction n'est qu'un for_each (ou iter...) en raisonnant de cette manière par exemple :
- on considère que Map<T, U> m est équivalent à une application m : T' -> U, où T' inclus dans T est fini
- block une fonction à effet de bord sur T * U

alors ta fonction mystère veut dire :

pour tout x appartenant à T, on exécute l'instruction block(x, m(x));

[super_navide]

Même si les closure aporte une complexité, elle permetent de facilité les itérations et l'écriture du code, moi je trouve que c'est ce qui manque à java.

Par contre que c'est vrai que la syntaxe de java ce complexifie et tend faire les même erreurs que C++.

C'est pour ca que j'apprécis bcp Smalltalk qui a une syntaxe ultra simple et efficace.

[pseudocode]

Et pourquoi tu voudrais faire ça ?
L'idée derrière, c'est que closure est une fonction, et non une classe. Est-ce que ça a un sens de vouloir en hériter, la redéfinir ?

Il n' y a aucune raison de "vouloir" le faire. Mais si on "peut" le faire, alors cela ce fera (loi de murphy).

L'idée de Java c'etait justement de faire en sorte que ca n'arrive "jamais", car on "ne peut pas" le faire... moindre danger => interdiction. C'est tres restrictif, mais c'est sécurisant. A partir du moment ou tu as 3 methodes pour faire un foreach, il y en a 2 qui ne sont pas les meilleures... et comment on décide laquelle prendre ? Des nouvelles règles, des nouvelles bonnes pratiques, des nouveaux DP... bref plus de chose a se rappeler, donc plus de risque d'erreur.

[HanLee]

Il n' y a aucune raison de "vouloir" le faire. Mais si on "peut" le faire, alors cela ce fera (loi de murphy).

Et dans les faits ? Si Java ne le permet pas, tant mieux, donc aucune raison d'en avoir peur.

L'idée de Java c'etait justement de faire en sorte que ca n'arrive "jamais", car on "ne peut pas" le faire... moindre danger => interdiction. C'est tres restrictif, mais c'est sécurisant. A partir du moment ou tu as 3 methodes pour faire un foreach, il y en a 2 qui ne sont pas les meilleures... et comment on décide laquelle prendre ? Des nouvelles règles, des nouvelles bonnes pratiques, des nouveaux DP... bref plus de chose a se rappeler, donc plus de risque d'erreur.

Ben, un algorithme, tu peux parfois l'écrire en itératif ou en récursif.
Java a-t-il interdit le style récursif ?

Idem, exécuter un foreach peut se faire en style fonctionnel ou impératif. Dans beaucoup de cas, l'un n'est pas meilleur que l'autre, mais parfois l'un est plus adapté et élégant que l'autre.

C'est inévitable, à partir du moment où tu as un langage à orientation impérative qui te permet de manipuler des fonctions/méthodes.

Enfin, on peut considérer que le style avec classe anonyme n'était qu'un hack, tout comme C++ simule cela de la même manière avec les classes locales.

[screetch]

Personnelement, je trouve qu'il est plus dur de faire un "bon" programme C++, qu'un "bon" programme Java.

par "bon", je parle de lisibilité, de maintenabilité, d'extensibilité, de respect des paradigmes/regles, de fiabilité, et bien sur de perfomances.

Le C++ permet de TOUT faire, fonctionnellement parlant. Mais en terme de lisibilité, fiabilité, ... il faut etre un expert dans beaucoup de domaine:
- la programmation imperative (type C, avec variables globales)
- la programmation objet (type C++, avec instances de classes)
- la gestion structure/mémoire (struct/union/class, malloc/free/new/delete, tableaux/collections, pointeurs/reference/valeur)

Le Java permet de faire moins de choses que le C++, fonctionnellement parlant (pas de jeux, pas de drivers, ...) . Mais il est beaucoup plus facile de faire un "bon" programme car seule la maitrise du paradigme OO est necessaire.

Une fois que le design d'une classe est choisi (UML/Pattern), il n'y a generalement qu'une seule maniere de la coder (syntaxe restreinte, compilateur stricte, JDK standard).

En C++, on a toujours des "choix" possibles au mement de coder. Ce sont ces choix qui permettent des optimisations au niveau "performance" qu'on ne pourra pas faire en Java. Le probleme, c'est qu'un non-expert risque souvent de faire un mauvais choix pour des raisons de facilité d'ecriture.

Bien sur, ca n'empeche pas qu'il existe des mauvais programme Java (une classe, tout en static ) et de tres bon programme C++. Mais, de par mon experience, je trouve qu'il est plus facile d'analyser, comprendre et corriger une appli Java qu'une appli C++.

Petite question: Combien de règles faut-il respecter pour faire un "bon" programme C++ ? Et Java ?

salut, je deterre!

il est difficilement soutenable que laisser le choix de la methode est un desavantage. Je concois que dans le mauvais cas, le C++ permet de cumuler les bourdes.

Mais le fait que C++ offre plus de paradigmes de programmations permet de choisir la meilleure solution pour obtenir un resultat. Du temps ou j'utilisais java, il n'y avait pas de templates; donc je ne sais pas ce que c'est devenu. Mais la programmation générique en C++ a sauvé mes petites fesses des miyards de fois et tant qu'il n'y aura pas de moteur de template aussi puissant en java qu'en C++, je ne me mettrais pas a java.

Pour conclure, C++ permet d'ecrire des programmes partant de la nullitude la plus crasse pour atteindre une qualité correcte. En java, le pire que l'on puisse faire est mediocre et le mieux que l'on puisse faire est mediocre mais un peu mieux.

Nous sommes supposes maitriser le C++ et ne plus ecrire la nullitude; meme si de nombreuses choses sont perfectibles dans ce que j'ecris, je l'ecris mieux que je ne pourrais l'ecrire en java avec les memes connaissances; car Java et son paradigme OO permet de resoudre des problemes de facon moins concises que les templates du C++.

En revanche j'aurai pas craché sur l'introspection en C++, j'ai fini par la coder moi meme et ca alourdit mes interfaces.

[pseudocode]

salut, je deterre!

Amis zombis, bonsoir...

il est difficilement soutenable que laisser le choix de la methode est un desavantage. Je concois que dans le mauvais cas, le C++ permet de cumuler les bourdes.

Je n'ai pas dit que c'etait un désavantage, mais juste un risque supplémentaire.

Pour conclure, C++ permet d'ecrire des programmes partant de la nullitude la plus crasse pour atteindre une qualité correcte. En java, le pire que l'on puisse faire est mediocre et le mieux que l'on puisse faire est mediocre mais un peu mieux.

?! C'est pas un peu exagéré, quand meme ? J'ai beau aimer le C++, je peux quand meme pas dire que JBoss, Struts, Tomcat, Spring ou Hibernate sont "mediocres".

Ma conclusion du jour:

J'aime le C++ pour des raisons techniques.
J'aime Java pour des raisons pratiques.

[Garulfo]

Ouch, tellement faux ...

2 façons d'optimiser, algorithme, et implementation de l'algorithme.

Pour l'algo lui meme, le compilateur ne fait rien.
Pour l'implementation, le compilateur n'optimise que sur du court terme ( sur la longeur d'une fonction, par exemple).

Pour n'importe que bout de code plus long que ton exemple, rien ne peut remplacer un cerveau humain .....

C'est très loin d'être évident ce que tu dis.
En fait en général le compilateur C écrit du meilleur code (plus rapide) que du code assembleur à la main.

Certes la règle n'est pas valide à 100%. Mais l'ordinateur gagne plus souvent actuellement que l'humain aux jeux des optimisations. La recherche a bien plus évolué que tu ne le penses visiblement. Pseudocode ne donnait pas une règle définitive, mais je suis complètement de son avis. De nos jours les problèmes de performances sont principalement dus à des erreurs de conception et non à du tweaking (cf. les chiffres compilés par Boehm)

La performance est devenu un enjeu de moindre importance dans l'industrie du logiciel, si on met de côté des aspects comme le calcul scientifique. Mais ce dernier ne représente pas qu'une petite part de l'industrie. Le problème est dans les algorithmes et plus beaucoup dans les petites optimisations.

Maintenant les algorithmes sont fait par des humains. -_- Dire que les algorithmes font mieux qu'un humain moyen, c'est dire que qqun a fait un coup génial, et non que la machine a battu l'humain.

[Garulfo]

[...]
Par contre que c'est vrai que la syntaxe de java ce complexifie et tend faire les même erreurs que C++.

C'est pour ca que j'apprécis bcp Smalltalk qui a une syntaxe ultra simple et efficace.

On s'entend que Java est le digne héritier de Smalltalk ??
Ils ont pris la syntaxe du C/C++ pour des raisons commerciales et pour attirer l'industrie, mais la philosophie est celle du Smalltalk. Mes vieux collègues (pourvus qu'ils ne me lisent pas ) adeptes de la première heure de Smalltalk ne me démentiront pas. Bon cependant, attention je n'ai pas dit que Java est Smalltalk. Ces mêmes collègues ont tendances à détester Java... tout autant que C++ d'ailleurs.

[super_navide]

Java est l'héritier de Smalltalk et du C++.
Mais je préfère le couple Smalltalk + C(C++) qui je pense est bien meilleur que java seul ou C++ seul.

N'importe qui peut programmer en Smalltalk même un enfant.

Mais je dois dire que Java aujourd'hui est très puissant il y a une communauté de développeur importante et les environements de développement sont très puissant (mais un peut lourd ) et il y a bcp de framework autour.

je me suis mis a java à partir de la 1.5 car je trouve que ce qu'il manquait a java c'étais les générics.

[super_navide]

Existe-il en C++ un framework comme bcel ou asm.objectweb de java qui permet de générer des classes en runtime.
Je pense que non car j'ai longtemps chercher un tel framework .

[Kujara]

C'est très loin d'être évident ce que tu dis.
En fait en général le compilateur C écrit du meilleur code (plus rapide) que du code assembleur à la main.

En general, oui.Mais dès que tu creuse un peu et que tu commence a faire des choses compliqués....

La recherche a bien plus évolué que tu ne le penses visiblement

En tant que professionel, seul les outils actuellement disponibles m'interessent.

Je me doute bien que quelque part sur cette planete, un groupe de petits malins ont crée un compilateur qui optimise correctement, ou sont en train de.

Mais pour l'instant, les outils actuels ne le font pas .... ( vc++ 8 sp1, gcc derniere version, etc ...).

Le problème est dans les algorithmes et plus beaucoup dans les petites optimisations

Quand l'algorithme est connu, et totalement optimisé ( prouvé mathematiquement comme optimal ), la difference est dans l'implementation ....

[Kujara]

Existe-il en C++ un framework comme bcel ou asm.objectweb de java qui permet de générer des classes en runtime.
Je pense que non car j'ai longtemps chercher un tel framework .

Tu peux chercher >.<

En theorie c'est possible ( assembleur recompilé direct en mémoire, puis sauter sur ces bouts de code).

Mais c'est tellement contraire aux fondements du c++ .....


...



Maintenant que j'y reflechis, ça pourrait etre très, très amusant ...
Merci pour l'idée ^^