Discussion :

[Clement Cunin]

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

On peut meme commancer des maintenant en "patchant" le compilateur.
http://faqjava.developpez.com/?page=...ATION_template
http://developer.java.sun.com/developer/technicalArticles/releases/generics/

Java 1.5 est prevus pour la fin de l'année, cette argument n'en est plus un. :-)

[luthier]

Je n'ai pas lu tout le thread, désolé si ça a déjà été relevé, mais j'aimerais relever qu'un point fort du Java est l'API javadoc en ligne sur le site de Sun, qui permet de retrouver très facilement n'importe quelle classe ou méthode et son utilisation. Ca facilite énormément le développement, surtout quand on n'a pas assez de mémoire interne dans le cerveau pour tout retenir :-)

En C ou C++ c'est toujours plus difficile de récupérer la doc, et c'est pas toujours dans un format aussi bien présenté et pratique que le javadoc. J'ai systématiquement un browser avec un javadoc sous le coude quand je développe en Java et je m'y réfère très régulièrement. Avec le C ou C++ ça dépend souvent de la doc qui vient avec l'EDI, ou alors des bouquins papier que je peux avoir dans ma bibliothèque...

[Mandrake]

Il faut faire attention au terme qu'on emploie, en disant qu'un langage est plus complet ou permet de faire plus de choses.

C++ est un langage "universel" dans le sens ou l'on peut en théorie tout faire avec (systèmes d'exploitation, logiciels, jeux, drivers, programmes pour des robots d'usine...) sur n'importe quel type de machine. Java semble plus restreint, cependant les applis java tournent sur n'importe quel machine ayant une JVM.

Java est "plus complet" dans le sens ou l'API standard de java est extrêmement riche (SGBD, traitement syntaxique, collections, réseaux...) en comparaison au C ou au C++. Pour faire la même chose en C ou C++, il faut faire appel à des librairies non standard. Ces librairies ne sont pas disponibles sur toutes les plate-formes.
Si on veut développer des applis conséquentes en C/C++, on utilisera des outils de développement spécifiques (Visual C++, KDevelopp...) et des librairies spéciales, très puissantes mais le résultat sera un programme non portable.

[Elrond]

Je n'ai pas lu tout le thread, désolé si ça a déjà été relevé, mais j'aimerais relever qu'un point fort du Java est l'API javadoc en ligne sur le site de Sun, qui permet de retrouver très facilement n'importe quelle classe ou méthode et son utilisation. Ca facilite énormément le développement, surtout quand on n'a pas assez de mémoire interne dans le cerveau pour tout retenir :-)

En C ou C++ c'est toujours plus difficile de récupérer la doc, et c'est pas toujours dans un format aussi bien présenté et pratique que le javadoc. J'ai systématiquement un browser avec un javadoc sous le coude quand je développe en Java et je m'y réfère très régulièrement. Avec le C ou C++ ça dépend souvent de la doc qui vient avec l'EDI, ou alors des bouquins papier que je peux avoir dans ma bibliothèque...

A condition d'etre connecte sur internet en permanence pendant que tu developpes. Ce n'est pas le cas de tout le monde (y compris les professionnels).

Dans le cas ou tu l'es, tu peux toujours acceder a MSDN en ligne pour le C++ (ou d'autres que je ne connais pas). Par contre il me semble effectivement que la doc Java est plus claire.

Si tu n'es pas connecte en permanence, alors dans les deux cas tu dois t'arranger pour telecharger des docs sur ton ordinateur.

[Anomaly]

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

J'ai eu le courage de lire l'entièreté du thread en une matinée, et je vois que beaucoup de personnes ici pensent que les templates est la panacée. Dans l'idée, c'est excellent. Mais l'implémentation en C++ est très délicate. Essayez de faire une fonction amie template d'une classe template... Vous en avez pour plusieurs heures à tâtonner pour trouver la bonne syntaxe. De plus, l'implémentation des templates par gcc (du moins la version 2.x) se traduit par une duplication du code généré dans chaque module ce qui produit un exécutable qui grossit à chaque utilisation de template. Quand on sait que l'un des avantages de C/C++ par rapport à d'autres langages (je ne pense pas à Java ici) est de pouvoir générer un code petit et rapide, je trouve ça bien dommage. Si les templates arrivent en Java, j'espère qu'ils le seront d'une manière bien plus réfléchie !

Sinon, pour en revenir sur le sujet même du débat, l'opposition C++ / Java, j'aimerais mettre le doigt sur deux points particuliers des exceptions qui n'ont pas été encore levées :

En C++, en cas d'exception, les objets alloués sur la pile sont libérés automatiquement, mais les objets alloués dynamiquement ne le sont pas. Pour libérer ces objets, on doit le faire non seulement dans le cas où aucune exception ne se produit, mais aussi dans le cas où une exception se produit, vu qu'on ne peut pas définir de section de code a exécuter qu'une exception se produise ou non.

En Java, les objets sont libérés par le GC, et il est possible de définir cette fameuse section à exécuter dans tous les cas (finally).

Donc ici, net avantage au Java.

En revanche, comme vous le savez, il est indispensable en Java de déclarer les exceptions qui "sortent" d'une fonction ou de les capturer. En langage technique, on appelle ça des "checked exceptions". En C++, c'est possible, mais pas nécessaire.

Quel intérêt à obliger la capture des exceptions ? J'ai souvent lu dans ce thread que un avantage du Java par rapport à C++ est une plus grande productivité du programmeur. Il y a des erreurs qu'il ne sert à rien de capturer et de traiter, parce qu'elles sont fatales, et donc un arrêt du programme se révèle être la meilleure solution. Mais en Java, à moins que ces erreurs soit dérivées du RuntimeException, on est obligé soit de déclarer que ses exceptions sortent, soit les capturer.

Un avantage du système d'exceptions par rapport au système classique du retour du code d'erreur est de soulager le programmeur de tester systématiquement les erreurs possibles, et surtout de ne pas les négliger si elles arrivent. Qui en C par exemple teste que la fonction de création de socket socket() ne renvoie pas -1 ? Et pourtant ça peut arriver dans un cas rarrissime : utilisation d'un noyau linux sans le support TCP/IP. Dans ce cas, il n'y a pas de traitement à associer à cette situation, et le programmeur ne devrait pas être obligé de prévoir le cas tout en s'assurant que le programme ne s'exécute pas dans de telles conditions.

Or en Java, c'est obligatoire de gérer le cas. Alors, ce qui arrive quand on débute, on est énervé par cette gestion des exceptions, alors on entoure l'expression correspondante d'un try { ... } catch (Exception) {}. On se dit : c'est temporaire, je gèrerai l'erreur plus tard... Mais on oublie. Et ainsi on arrive dans la pire des situations possibles : a) l'erreur est ignorée, b) on se sent néanmoins en sécurité (à tort).

Le C# n'oblige pas la capture (on parle donc de non-checked exceptions) pour éviter une telle situation. Une amélioration de Java serait de lui aussi rendre optionnel la capture des exceptions.

Sinon, les reproches que je ferais à Java est la lourdeur de son fonctionnement. Certes les processeurs puissants actuels peuvent réduire l'effet du byte-code et des tests systématiques, mais néanmoins une appli Swing a toujours l'impression de "ramer", et ça fait vraiment mauvais effet sur une machine qui n'est pourtant pas sortie du garage (Oracle 8 sur un Duron 1,3 GHz). La portabilité de Java est malheureusement illusoire dans le cas des applets Internet : déjà, il vaut mieux vous passer de Swing ; et je n'ai pas vu une seule applet apparaître correctement ou de manière identique sur tous les navigateurs et OS (y compris en utilisant le même navigateur, même JVM, et juste en changeant l'OS).

Les reproches au C++ que je ferais est le fait que c'est très difficile de maîtriser à 100% ce langage ; il comporte tellement de détours, de détails, de tweaks... Il faut faire très attention à ce qu'on fait, il y a des pièges dans lesquels on peut trop facilement tomber (renvoyer une référence vers un objet local par exemple), les erreurs générées par un code C++ sont parfois très difficiles à comprendre car la raison même de l'erreur se trouve bien auparavant ; une erreur dans un template est probablement la pire des choses qui peut arriver pour le programmeur moyennement patient

C'est pour ça que je suis revenu au C, un langage certes sans objet, mais dont je pense connaître toutes les subtilités, contrairement au C++... Mais bon, c'est aussi parce que je dois être puriste sur les bords

[Causa Sui]

il comporte tellement de détours, de détails, de tweaks... Il faut faire très attention à ce qu'on fait, il y a des pièges dans lesquels on peut trop facilement tomber

Même si je suis convaincu que C++ est un de meilleurs (le meilleur aprés ASM ) je dois reconnaitre que ce n'est pas un language simple... Il tire de C sa complexité et ses danger de bases, et les structures C++ en rajoutent encore... Cela dit je crois que toutes ces difficultés peuvent etre surmontée et il ne faut pas d'office se tourner par découragement vers java qui vous "materne" plus et ou faire une erreur est assez difficile (je c je carricature un peu)

[jorix]

entierement d'accord avec toi, de plus, souvent on dit que java est plus portable que c++.
Je me permet de dire que si l'on utilise du code pur jus, on est totalement portable (voir la liste des plateformes que peut supporter gcc on ne trouvera pas mieux).
Pour les interfaces graphiques il y a Qt (utiliser par kylix et c++ builder)
qui permet de passer de win32 à linux (et unix) en passant par mac os sans changer un iota de code. Que demande le peuple !

[vdemeester]

entierement d'accord avec toi, de plus, souvent on dit que java est plus portable que c++.
Je me permet de dire que si l'on utilise du code pur jus, on est totalement portable (voir la liste des plateformes que peut supporter gcc on ne trouvera pas mieux).
Pour les interfaces graphiques il y a Qt (utiliser par kylix et c++ builder)
qui permet de passer de win32 à linux (et unix) en passant par mac os sans changer un iota de code. Que demande le peuple !

Gtk+ est aussi comme Qt des interfaces graphiques portable... il en existe même plein d'autre mais autant utiliser les plus connu, les plus distribuée

[512k]

Je crois que rien que le classe String de JAVA montre toute la puissance et l'interêt de JAVA.
Mais les points forts que je connais de java c'est:
le réseau (c'est archi simple),
l'IHM (les fenêtres, plus facile qu'en c++)
le multitaches
et le reste (ouvrir un bouquin de java)

Les défaut? des trucs idiots du style comment on fait pour avoir la taille d'une partition sous JAVA? moi j'ai pas trouvé
lancer ton application java simplement quand tu es débutant et de la meme manière qu'un .exe?

[Causa Sui]

Les défaut? des trucs idiots du style comment on fait pour avoir la taille d'une partition sous JAVA? moi j'ai pas trouvé
lancer ton application java simplement quand tu es débutant et de la meme manière qu'un .exe?

Je crois que tu oublie aussi:
-Lenteur relative par rapport à C/C++ (java est interprété et C++ compilé)
-Manque d'un "couche" de bas niveau qui permet de construire des application systeme
-... (regarde plus haut!)

De plus il existe dans aussi un type String dans une des biblis sandard de C++, et en vertion Visual, C++ contient des fonctions relatives au multithreading.

[ohnerom]

Bonjour,

je fais du dev JAVA depuis 5 ans dans un env. professionnel. site WEB ( ebanking) , applications classsiques ( SWING) et services EJB pour remplacer des services CORBA ( C++ ) .

Je ne suis pas un grand spécialiste du c++ alors je peux pas comparer techniquement.

par contre je peux vous parler de JAVA :

j'aime :

- robustesse ( ca tourne bien sans bleme bizard dont on ne s'est pas pourquoi il faut redémarrer, plante jamais le serveur HOST, libère la mémoire utilisée à l'arret de la JVM
- élégance du langage ( très perso )
- cohérence ( on connait bien une lib , on peut passer à une autre sans difficulter )
- librairie technique dissocicée par des interfaces ( JDBC, ORB CORBA , etc . permet de choisir l'implémentation technique d'une couche particulière )
- déploiment ( mon préféré : je peux faire des soft d'installation qui pose des fichiers simplement ( pas de registry, pas de regsvr32 etc. ) quelque params dans un fichier textes et ca marche qqe soit les JVM et autres libariaire présentent sur la machine. Je peux dire que juste avec ca , on arrive convaincre beucoup de decideurs. vécu
- nombreux soft gratuit de tres bonne qualité : ANT, LOG4J, CASTOR
- secondaire dans mon cas : la portabilité. par contre , c'est sympa de faire des petits soft pour son PALM ou REVO en JAVA qui gere ses DVD

- ensuite choix du IDE ( très perso, maintenant ECLIPSE, nombre de plugin hallucinant : UML, VSS, XML, pas de soft d'install, etc.. )

donc en tant que professionnel ( du moins j'espère ) j'ai peu de reproche à faire à JAVA . sauf peut etre la libriaire SWING , j'ai découvert SWT ( utilisé par eclipse )

Cordialement,

[512k]

:Causa Sui
En effet tu as en partie raison, désolé j'ai surtout jugé les défaut de Java par rapport a ce que j'ai fait dessus, pas vraiment par rapport au C++.(j'avoue kan lisant ton message le mien faisait très mauvaise foi)
et avec ce que j'ai fait en programmation, je n'ai à repprocher à java que les défauts que j'ai mentionné.

Voila mon avis sur le c++:
Personnellement je trouve C++ très complet, offrant énormenent de possibilités, mais un peu fouillis...
(le rêve d'un langage de bas niveau et de haut niveau, cf mon prof de prog, pourkoi pas un jour un langage qui programme tout: asm, web, prolog(vade retro)... )

Ps:La lenteur je m'en fiche, c'est kan meme un vrai défaut mais ça pas empêché crosoft d'ariver là où il est, et la puissance Cpu de doubler tout les 18 mois.

Conclusion: Apprendre les deux c'est mieux, on est mieux payé, plus polyvalents et on profite des avantages des deux langages, le pas cool c'est kan on programme avec l'un et que 1 avantage de l'autre n'est pas disponible, ex: les string en java c genial, l'équivalent C++ c carrement moyen, ya plein d'exemple contraires évidement.

Sinon il reste JNI en java pour marrier les deux, complexe pour moi(j'y suis arrivé kan meme), facile pour des guys expérimentés...

[Causa Sui]

Au fond aprés avoir apris les base du java il y a une chose qui me marque vraiment: le manque de souplesse par rapport a C++; j'entends pas la qu'avec java, on n'a pas le choix: on doit faire de l'objet!
Cela ne pose pas vraiment de proble de compréhension mais pour dans certain cas ceci (exemple simpliste):

Code :

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

1
2
3
int produit(int x,int y){
  return x*y;
}

est plus simple que:

Code :

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

1
2
3
4
5
class produit {
  public static int produit(int x,int x){
    return x*y;
  }
}

Et surtout, la premiere solution semble plus logique!

Aussi dans un souci de simplicité des chose interessantes ont été supprimée de C++ a java:
-héritage multiple (même s'il existes l'extension de plusieurs interfaces)
-pointeur (et donc le choix entre passage par valeur ou reference/pointeur)
-droit a gérer sois même la mémoire (avec new/delete, les déstructeurs)

J'aime surtout dans C++ le droit qu'on a de faire presque ce qu'on veux.

Cependent je crois qu'a l'avenir l'industrie de l'informatique va s'orrienter dans le sens de languages comme java pour des raison de sécurité, de portabilité. Je crains qu'il ne faille plus compter sur la création de nouveaux langues d'aussi bas niveau que C++.

[Flint]

Cela ne pose pas vraiment de proble de compréhension mais pour dans certain cas ceci (exemple simpliste):

Code :

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

1
2
3
int produit(int x,int y){
  return x*y;
}

est plus simple que:

Code :

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

1
2
3
4
5
class produit {
  public static int produit(int x,int x){
    return x*y;
  }
}

Et surtout, la premiere solution semble plus logique!

Peut être mais l'exemple n'est pas très significatif car on ne va certainement pas coder une classe en java juste pour faire l'opération produit, ce serait réinventer la poudre non ? D'ailleurs, on ne fera sûrement pas non plus une fonction en C++ pour ça.
Globalement dans une application, si tu fais du JAVA tu essayes de regrouper des opérations simples dans une seule classe .
D'autre part être "tout objet" ne me semble pas être un désavantage ni un manque de souplesse.

Je viens de passer de 4 ans de JAVA au C++, et j'avoue que j'ai du mal à m'y faire. Pour JAVA, quand je voulais savoir ce que faisait une classe, un package, hop, le site de sun, APIS super bien documentées, claires (en anglais mais bon).
Je n'ai retrouvé ça nulle part aileurs pour le C++.

Petite précision, j'utilise C++ Builder, et je trouve ça nul l'aide est minable, il faut à tout prix désactiver la complétion du code et l'aide contextuelle si on ne veut pas perdre des heures à attendre que le logiciel veuille bien nous rendre la main. L'accès au bases de données, n'en parlons pas, il y a 36000 façons d'y accéder, évidemment pas d'aide claire la dessus pour te dire dans quel cas utiliser tel moyen, obliger de déployer un moteur BDE de plusieurs mégas sur le client, on croit rêver.

Je crois que vous avez compris lequel des deux je préfère mais, je ne nie pas que les deux sont très utilisés.

[Causa Sui]

Et bien, tu n'es pas un fan de C++ (jolis euphémisme)...
Cela dit j'aimerais te répondre sur trois choses:
D'abbord je suis d'accord que C++ ne jouit pas d'une aussi bonne documentation que Java. Mais en général, et même si c'est un peu plus long (environ 1/2 minute de plus), il y a toujours moyen de trouver sur internet (merci google). Le web est vaste et il est rare (voire très rare) que je ne trouve pas ce qu'il me faut.
Personnelement je n'utilise pas Builder, et je ne peux rien répondre la dessus. Si c'est pour faire des application windows (???), tu peux utiliser VC++, qui lui à une documentation à toute épreuve (MSDN, également en anglais).
Enfin, je crois m'être mal exliquè avec mon exemple; je voulais juste dire que le fait de créer une classe pour des opérations, mathématiques par exemples, est un peu contre-nature (inutilité des instances d'un objet mathématique, inutilité totale de l'héritage et des interfaces). Bref dans certains cas la programation orientée objet est superflue, voir illogique.

Quoi qu'il en soit, je ne pense pas arriver à te convaincre. Tous les languages doivent faire des compromis, et au final, tout est une question de choix.

[Flint]

C'est bien de pouvoir discuter sans se prendre la tête

Alors voilà :
En ce qui concerne la doc, c e que j'apprécie, c'est que ce soit très centralisé en java (pas 40 000 sites de référence) et j'ai rarement besoin d'aller sur un forum demander des conseils pour m'en sortir.
C'est vrai que sur le net on peut trouver beaucoup de choses sur le C++, mais avec builder (ce doit être cet environnement qui est un peu pénible) j'ai du en faire des posts car l'aide est vraiment nulle, et du coup, vive le forum. Cela dit parfois je m'apercevais qu'il était impossible de faire certaines choses pourtant basiques, de façons simple.
D'autre part, il a souvent été dit que la liberté en C++ était totale, c'est vrai, mais pensons aux pauvres débutants dans ce langage (moi par exemple) qui arrivent à en faire des conneries justement dûes à la souplesse du langage. Là encore, je pense qu'il s'agit d'un problème d'information, pourtant, le C++ est moins récent et devrait bénéficier d'une expérience et d'une normalisation béton, mais ça n'a pas l'air d'être le cas. Mais bon, en fait je pense aussi que je n'ai pas encore eu suffisament le temps de me pencher sur le problème, car j'ai du m'y mettre très vite et j'ai eu du mal à trouver mes marques en sortant du java pour aller vers le C++.

Mais c'est vrai que c'est bien de connaître les deux.

[Luc Hermitte]

C'est vrai que sur le net on peut trouver beaucoup de choses sur le C++, [...]
le C++ est moins récent et devrait bénéficier d'une expérience et d'une normalisation béton, mais ça n'a pas l'air d'être le cas.

C'est bien le cas. Avec des sites comme ceux de dinkumware ou de roguewave, on a une bonne description des fonctions de la STL. Elle n'est pas exceptionelle, mais une fois que l'on a compris son principe et que l'on sait ce que l'on peut attendre d'un container, cette doc suffit amplement.

C'est bien le cas (bis). Autrement, oui il existe une expérience sur le C++. Encore, faut-il savoir où aller la chercher. Perso je le fais sur usenet et dans les bouquins, principalement ceux de la gamme avancée chez addisson Wesley -> p.ex. les bouquins de Scott Meyers ou Herb Sutter qui sont assez incontournables en ce qui concerne le référencement des pièges et choses à savoir sur le C++. La FAQ C++-lite est très bien aussi.

Ce genre de bouquins commence juste à faire son apparition pour le Java il me semble.

[sequentaire]

Enfin, je crois m'être mal exliquè avec mon exemple; je voulais juste dire que le fait de créer une classe pour des opérations, mathématiques par exemples, est un peu contre-nature (inutilité des instances d'un objet mathématique, inutilité totale de l'héritage et des interfaces). Bref dans certains cas la programation orientée objet est superflue, voir illogique.

Dans une application il n'est jamais superflu de situer une routine, même très simple, surtout si elle est simple, parce que au bout de x temps à accumuler les routines simples, tu fini par ne plus savoir où elles sont. Donc, à mon avis, c'est bien que Java te force à situer une routine dans une classe, c'est à dire quelque part. Maintenant, il est toujours possible de passer outre en se donnant une classe appelée Toto, tout le monde a ses faiblesses.

Néanmoins j'admets que des instances d'objets peuvent être conceptuellement inutiles, et que Java gère très mal les méthodes statiques. Dans ma pratique, je les utilise de moins en moins, et j'organise de plus en plus mes systèmes de façon à utiliser des objets. Et je trouve, de plus en plus, que les appels statiques sont en fait nuisibles, en tout cas en Java.

Concernant la petite routine faite sur le gaz que tu ne peux pas faire facilement parce que tu es obligé de faire des classes et tout le saint fruscin, tu peux utiliser le BeanShell. C'est un langage de script très pratique, qui suit exactement la syntaxe de Java, et qui te permet d'écrire directement System.out.println(...) sans avoir à l'intégrer dans des classes. C'est très pratique pour te auto-former à des bibliothèques que tu ne connais pas.

[Flint]

Néanmoins j'admets que des instances d'objets peuvent être conceptuellement inutiles, et que Java gère très mal les méthodes statiques. Dans ma pratique, je les utilise de moins en moins, et j'organise de plus en plus mes systèmes de façon à utiliser des objets. Et je trouve, de plus en plus, que les appels statiques sont en fait nuisibles, en tout cas en Java.

Tu pourrais développer ça ?
En quoi c'est mal géré, en quoi c'est nuisible ? Je ne vois pas trop.

[sequentaire]

Là c'est plus spécifique Java

Je n'aime pas les méthodes statiques en Java, parce que elles ne sont pas clairement identifiables, qu'elles ne tiennent pas compte de l'héritage, et que, conceptuellement, il est bien rare que la notion de statique soit vraiment pertinente (mais sur ce dernier point on est totalement hors sujet, alors je ne le développerai pas).

Concernant les problèmes d'identification, j'en vois 2 :

1. si on a une classe statique stat dans un objet de classe X, on peut écrire X.stat(), mais on peut aussi écrire, sur un objet x de classe X : x.stat(). Cette dernière forme prête à confusion, car on risque de croire que stat est une méthode d'instance, hors c'est une méthode statique.
2. Alors que l'appel des méthodes d'instance dépend de la classe réelle de l'objet sollicité, l'appel des méthodes statiques dépend de la classe déclarée de l'objet sollicité. Cela ajoute à la confusion.