Discussion :

[Clement Cunin]

Tout ce que Java fait, c++ peut le faire, bein que cela soit plus difficile a mettre en oeuvre.

C++ permet-il de faire un programme managé ? NON
C++ permet-il de faire un programme portable ? NON

Java peut-il inclure de l'asm ? Oui, via JNI mais c'est vraiment pas le but du langage.

Oui, la JVM est codé dans un langage qui permet la compilation en natif et l'acces direct à la mèmoire et aux autres ressources. Java ne depends pas du C/C++, mais d'un programme compiler en natif comme n'importe quel autres langages interprétés ( perl, python, php, tcl, c#, ASP.net, basic, bash, csh, logo ...)

[neo.51]

C++ permet-il de faire un programme managé ? NON

Pour info avec VC++.NET on peut faire du code managé, les classe C++ .NET peuvent ensuite être appellé en C#, VB.NET, etc...

Bon par contre c'est vrai que c'est "l'excéption qui confirme la règle"

[Clement Cunin]

Evidement que VC++.NET le permet puisque c'est un langage de la plateforme dotNET... mais du coup, tu perds la possibilité de faire un OS...

VC++.NET est exclut de se debat :-)

[BenoitM]

Avantage de java

Un code portable
Grâce a la machine virtuel de java (JVM), les applications écrite en java sont portable sur toutes les différentes plate-forme qui implémente celle-ci.

Complètement objet
Ceci permet de crée un modèle hiérarchique.

Une API complète fournie par défaut.
Les objets et leurs fonctions sont donc standardisé. Ce qui permet une facilité d’utilisation et de lecture.

Une documentation simple et efficace sur le net.
Le site de java comprend le détaille de l’api ce qui facilite les recherches, il comprend aussi de nombreux tutoriaux.

Applet Servlet JSP
L’applet est une application qui se télécharge et s’exécute à partir d’un navigateur.
La servlet est son opposé elle s’exécute du coté serveur et permet de faire des sites dynamiques.
Le JSP est une réponse de Sun a la sortie de l’ASP. C’est deux-ci permet la séparation du code de présentation et celui de fonctionnement. Ce qui aide le web designer
Tout ces application peuvent être codé en java tandis que l’ASP de Microsoft s’effectue en Visual basic.

Le garbage collector .
Le garbage collector s’occupe de la gestion de la mémoire. Celui qui s’occupera de la suppression des objets qui ne sont plus utilisé. Il évite ainsi de nombreux problème au programmeur

Incoveniant

Lenteur
Le garbage collector et l’appelet a la JVM ralenti quelque peut l’application mais ceux-ci sont améliore avec les différentes version des JVM. De plus avec les pc actuelle c’est désagrément son pratiquement nul.

Pas de surcharge d’opérateurs.
Contrairement au langage c++, Java n’a pas de surcharge d’Opérateur ceux qui peut-être un désagrément avec des classes qui représentativité des matrice ou des vecteurs.
Ca alourdi aussi l’utilisation des type primitifs car on ne peux utiliser les Objets représentant des types primitif pour faire des opération mathématique dessus.
Pas d’héritage multiple

Java n’a pas d’héritage multiple mais cela peut-être néanmoins résolu par l’utilisation d’interfaces.



Vous etes d'accord?

D'autre chose a signalé?

[Elrond]

Vous etes d'accord?

D'autre chose a signalé?

Compare a C++?

L'absence de templates est un inconvenient, bien que quelqu'un ait dit que c'est en preparation.

Le fait que Java soit objet n'est pas specialement un avantage par rapport a C++ car celui-ci peut etre code de facon completement objet. C++ permet en plus facilement de faire du non objet.

[Clement Cunin]

Pour la lenteur, tu le dis toi meme, les nouvelles versions de la JVM sont vraiment plus optimisé, et elle le seront encore plus dans le futur... (95% des ressources processeurs d'une station de bureau sont inutilisé)

La surcharge des operateurs n'est pas necessaire, voir dangereuse car elle nuits à la lisibilité du code. Que veux dire l'operateur [] sur la classe Client ?

Pour les problèmes lié au type primitif, Sun nous prepare une solution a se problème avec de l'autoboxing dans Java1.5 (je me suis pas encore renseigné sur les detail de l'opération)

Pour l'heritage multiple, c'est un fondement du langage. Java utilise la delegation la ou C++ utilise l'heritage multiple. C'est une question d'habitude. Les interfaces permetant un transtypage multiple.

[BenoitM]

Humm en parlant de la surcharde d'operateur je veux surtout faire réference aux =, +,-,*,/ qui ont un sens pour des matrices, des vecteurs et surement d'autre classes
(Si il y aura eu des operateur de langage, on aurait pu avoir :

Code :

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

1
2
3
Integer i(1),j(3);
j=i+j;
String=j.toString;

Sans devoir passer a chaque fois par Integer.toString(i,j); ce qui pour moi alourdi le code quand tu as plein de Parse et toString
J'aurais aimer utiliser la classe Integer plustot que le type primitif integer


Le probleme des templates ne peut pas être résolu par des interfaces?


Pour moi l'avantage d'etre completement object c'est d'avoir une hierachie qui de parcourir une arborescence
De ne pas avoir des fonctions qui sorte de nulle part et donc difficilement trouvable sans lire toute une librairie...

Bête exemple a 2 euro
Si je cherche un ToUpper je regarde toutes les fonctions de la classe String
Tandis qu'en c je dois regarder toute une libraires sans meme savoir dans la quelle le ToUpper est implémenté

[Elrond]

Pour moi l'avantage d'etre completement object c'est d'avoir une hierachie qui de parcourir une arborescence
De ne pas avoir des fonctions qui sorte de nulle part et donc difficilement trouvable sans lire toute une librairie...

Bête exemple a 2 euro
Si je cherche un ToUpper je regarde toutes les fonctions de la classe String
Tandis qu'en c je dois regarder toute une libraires sans meme savoir dans la quelle le ToUpper est implémenté

On parle de C++, pas de C

Avec Visual C++, quand je cherche cette fonction je vais voir la classe CString et ses fonctions, et pouf! je trouve la methode MakeUpper. Comme quoi ca peut aussi fonctionner avec le C++ -> hierarchie entierement objet (meme si je concede que ce n'est souvent pas 100% le cas, et les MFC ne sont pas exactement un exemple parfait de codage objet...).

Le fait est que le standard C++ est nettement plus restreint que celui de Java et s'appuie en partie sur le C non objet. Donc en partant uniquement du standard, il y a effectivement de grandes lacunes. Il est toutefois possible de coder entierement objet, en utilisant des librairies entierement objet.

[Tifauv']

L'avantage de Java pour moi est sa moins grande permissivité. Par exemple une classe publique doit être dans un fichier nom_classe.java. Sinon le compili refuse de continuer. Ca peut sembler lourd, mais ce sont des contraintes comme ça qui obligent les développeurs à une certaine méthode. Alors bien sûr, on peut programmer en non-objet en Java si on n'a qu'un seule classe considérée comme une bibliothèques. Mais on est naturellement porté à davantage concevoir ses projets.

Au contraire, le C++ doit supporter le C, et c'est à la fois un avantage et un inconvénient.
Un avantage car cela permet de reprendre facilement des éléments déjà existants (ex: réaliser une classe Thread simple utilisant la bibliothèque pthread codée en C).
Mais je trouve (d'après mon expérience) que ce mélange est gênant car il ne force pas à programmer en objet. Or c'était quand même le but premier non ?

Je préfère personnellement le Java pour de gros projets, principalement parce que je développe plus vite avec (et mieux je pense). Toutefois j'aime aussi le C et le C++ que j'utilise de temps en temps (avec Valgrind).

[Argh!]

C++ permet-il de faire un programme portable ? NON

bien sur que si le c++ peut faire des programmes portables, il suffit de respecter des normes et d'utiliser des librairies portables. la portabilité a dailleur longtemps été un tres gros avantage du C/C++.

et le fait de ne pas avoir a recompiler n'est, selon moi pas un avantage puisqu'il enleve la possibilité d'avoir du code optimisé pour un systeme precis.

[Clement Cunin]

bien sur que si le c++ peut faire des programmes portables

Quand je parle d'une application portable, je parle d'un truc qui se porte sans effort particulier... sans #ifdef dans les couche basse...

Entre Linux, Solaris et BSD, c'est manifique, c'est souvent les mêmes librairie, mais avec un petit detail qui change, juste pour te faire ch***. (La bibliotheque de manipulation des socket par example.)

Tous les projet de C qu'on a du developper dans le cours de système, c'est la meme galère, quand ca marche sous Linux, ca marche pas sur Solaris (Alors que c'est des systèmes très très proche, à 1 include pres la plupart du temp !)

[Argh!]

bon, alors pour ce qui est de la librairie standard, le suel prob de compatibilité dont jai entendu parler c'est l'histoir du 's' a <Math.h>
c'est sur que lon ne vas pas aussi loins avec la lib standard C/C++ qu'avec la lib Java.
mais comme je lai dit il existe de nombreuses lib qui sont portables sans probleme. je pense a :
* FLTK pour le windowing.
* OpenGL et GLUT pour la 3D.
* OpenAL pour le Son.
* pour la gestion du reseau, les socket sont theoriquement portables mais il semble que ca ne soit pas totalement le cas.
je ne m'y connais pas en base de donné donc je ne me prononce pas.

un autre truc.
les deux plus gros marché du logiciels sont windows et Linux or avec Wine on peut emuler windows (bon pas a 100% c vrai, mais ca marche pour la base) donc on se retrouve avec un aventage du Java. on code un programme sous Win sans trucs exotiques et on le fait tourner en version emulé sous linux sans le recompiler.
ca ne sert a rien diriez vous et vous aurriez raison. ca ne sert pas beacoups plus que de faire tourner un programme java sous plusieurs systemes.

[Tifauv']

Ca ne sert à rien diriez-vous et vous auriez raison. Ca ne sert pas beaucoup plus que de faire tourner un programme java sous plusieurs systèmes.

Pardon ? Il y a une différence fondamentale entre les deux.
1) tu fais un programme dédié à Windows, et tu essaye ensuite de la faire marcher ailleurs.
2) tu fais un proramme Java n'utilisant pas de spécificités système, et il est d'office portable.

L'objectif de base est différent. Dans le premier cas, tu développes d'abord une version spécifique en espérant qu'elle puisse passer sur d'autres systèmes (ce qui ne se réduit pas à Linux. Quid des BSD ? MacOSX ?). Dans l'autre, l'optique de départ est d'obtenir un programme compatible.

Ca n'a strictement rien à voir.

[Clement Cunin]

Le problème de portabilité des application C++ n'est pas du aux bibliotheque de haut niveau comme celle que tu donne, mais au fonction de bas niveau :
-> gestion des rezos par socket (Ca je sais par experience que pour chaque systeme, tu est bon pour une apres-midi de lecture de doc et une portabilité a coup de #ifdef)
-> manipulation du systeme de fichiers.


Ensuite, dire que les applications windows sont portable en utilisant wine, c'est du delire ! J'ai testé wine, c'est pas mal, on arrive a faire tourné certaines applications convenablement, mais on ajoute les bugs de wine au bugs de l'application, le resultat n'est pas toujours nickel !

En c++, a chaque etape du developpement, a chaque choix pour une nouvelle bibliotheque, tu dois reflechir pour rester portable... En Java, la portabilité est garantie du moment que tu n'utilise pas JNI, tu fais le choix en connaissance de cause de perdre la portabilité...

[Argh!]

donc C++ et Java n'ont pas le meme domaine d'application.
a ce moment la il ny a plus grand interet a les comparer.

si jai bien compris :
C++:

• portable en theorie
  garde la capacité d'etre optimisé
  peut servir a programmer a tres bas niveau

Java:

• Portable en pratique
  depends de la JVM sur laquelle il tourne (au niveau perf)
  pourrait servir a programmer a bas niveau mais c'est sans interet
  

[sequentaire]

C++:

• portable en theorie
  garde la capacité d'etre optimisé
  peut servir a programmer a tres bas niveau

Java:

• Portable en pratique
  depends de la JVM sur laquelle il tourne (au niveau perf)
  pourrait servir a programmer a bas niveau mais c'est sans interet
  

Je comprend à peu près ce que tu veux dire, mais je pense qu'il faut préciser que java a aussi la capacité d'être optimisé.

Au niveau de la portabilité, il me semble qu'il vaut mieux voir C++ comme un langage pour un environnement homogène, et Java pour un environnement hétérogène. Comme "homogène" et "hétérogène" sont des notions assez relatives, c'est mieux.

Cela confirme ce que tu dis : Java et C++ n'ont pas les même domaines d'application.

[Traroth]

Evidement que VC++.NET le permet puisque c'est un langage de la plateforme dotNET... mais du coup, tu perds la possibilité de faire un OS...

VC++.NET est exclut de se debat :-)

Ben en fait, c'est un peu le probleme de ce debat :
C++ est un langage, dont il existe un plethore de version, de GCC, sous Unix, permettant de faire du C++ pur, à VC++.NET, qui est un environnement de développement integré basé sur C++, integrant le framework .NET.
Java, de la meme maniere, est un langage de programmation, mais egalement un framework. Il existe de nombreux IDE
Au final, quand on dit C++ vs Java, on ne sait pas vraiment de quoi on parle. Du langage de programmation ? Du (des) framework ? La, on va vraiment avoir un probleme, parce que pour C++, on en pas qu'un seul, loin de là, et pour Java, il y a au moins le standard Sun et J#. Des IDE ? Difficile aussi de comparer : Pour Java comme pour C++, on a le pire et le meilleur.
Tout ça pour dire que si on veut comparer, il faut savoir ce qu'on veut comparer d'abord. Parler de code managé, ou de programmation d'OS, ça n'a pas vraiment de sens si on parle seulement de langage de programmation. On peut parfaitement imaginer une version compilée de Java (ça existe d'ailleurs), qui ne s'execute pas dans un environnement managé, et avec lequel on pourrait programmer des OS.
Maintenant, est-ce que Java est adapté à ce type d'usage ? On se rapproche deja plus du coeur du debat, maintenant.

[Marc Lussac]

Attention DotNET versus Java c'est ici :
http://www.developpez.net/forums/viewtopic.php?t=30401

Ici c'est C++ (non managé) sans DotNET versus Java (managé)

[Elrond]

Le probleme des templates ne peut pas être résolu par des interfaces?

A ma connaissance non. Je laisse les specialistes de Java confirmer pour la partie Java, mais voici ce qui je pense risque de poser probleme.

Le premier probleme est que l'utilisation d'une classe template ne necessite souvent pas de modifier la classe templatee. Cela permet en C++ d'appliquer le template meme a des classes que l'on ne peut pas modifier (ne nous appartenant pas).

Je ne suis pas sur pour Java, mais il me semble qu'il faille faire deriver la classe de l'interface.

Le second probleme est que la classe template C++ contient du code, alors qu'il me semble que l'interface Java (comme toute interface d'ailleurs) n'en contient pas. Il faut donc reecrire le code a chaque fois (meme si le copier coller peut sans doute faire une bonne partie du boulot). Pour le moins ca rend les fichiers sources plus lourds, et une modification doit etre reportee partout.

[Tifauv']

Les templates devraient être intégrés sous peu dans Java (1.5 ?)