Discussion :

[iolco51]

Moi j'ai une nette préférence piour le langage JAVA, d'une part parce qu'il a été entière pensé objet (alors que le C++ est une incrémentation du langage C destiné à l'adapter à la pOO), et d'autre part parce que JAVA offre des possibilités de portabilités appréciables sazns avoir à toucher le code source ni à recompiler.

Il faut tout de même évaluier les critères suivants :
- JAVA est moins appropriés pour des applications critiques en termes de ressources système, le garbage collector et (surtout) la machine virtuelle ralentissant notablement l'éxécution d'applications JAVA.
- JAva ne permet pas l'héritage multiple, en revanche son système d'interfaces est très souple.
- JAVA ne permet pas le gestion de la mémoire à bas un niveau .
- Hélas pas de compilation en code machine possible en JAVA.

[gregy]

Si je puis me permettre raisonner de la sorte laisse de cote une bonne partie de l'informatique. Si il est vrai que les PC qui sorte sont tres puissant il ne faut pas oublie le materiel embarque et tout les PCs anciens encore utilise dansl'industrie.

Pour info, il existe une plateforme java pour tout ce qui est informatique embarquée...

Et pour ce qui est des anciens pc ... ben on peut critiquer toutes les applications actuelles ecrites dans n'importe quel langage. Tu fais pas tourner un OS actuel (qui souvent sont écrits en C/C++ avec de l'asm) sour un ordi d'il y 10-15 ans ... Tout ca pour te dire que tout évolue .. sinon faudrait peut-être penser à tout écrire en asm.

Hélas pas de compilation en code machine possible en JAVA.

Il existe des compilateurs pour java... On va me dire c'est pas le but, certes, mais ca existe, sous win et si je m'abuse sous linux egalement (ou en tt cas c'est en projet).

[gl]

Si je puis me permettre raisonner de la sorte laisse de cote une bonne partie de l'informatique. Si il est vrai que les PC qui sorte sont tres puissant il ne faut pas oublie le materiel embarque et tout les PCs anciens encore utilise dansl'industrie.

Pour info, il existe une plateforme java pour tout ce qui est informatique embarquée...

Desole, mais je ne suis pas certains de trouver des VM pour toute l'info embarque. Deja contrairement a ce que ta phrase laisse penser, il ne peut pas y avoir une plateforme Java pour l'embarque pour la bonne et simple raison qu'il existe une multitude de systeme embarques differents. Maintenant si c'est vrai et que tu connais une VM qui tourne sur des systemes a base de µc Epson (ca doit etre du 8 bit a 4MHz je crois) avec en tout et pour tout 64 kO de memoire (code et donnee) et sans OS alors je suis preneur mais a ma connaissance ca n'existe pas.

Et pour ce qui est des anciens pc ... ben on peut critiquer toutes les applications actuelles ecrites dans n'importe quel langage. Tu fais pas tourner un OS actuel (qui souvent sont écrits en C/C++ avec de l'asm) sour un ordi d'il y 10-15 ans ... Tout ca pour te dire que tout évolue .. sinon faudrait peut-être penser à tout écrire en asm.

Tu ne fais pas tourner des OS actuels (windows XP par exemple) mais rien n'empeche d'utiliser des OS plus leger comme DOS, des Linux en install min ou des OS maisons sur lesquels tu peux faire tourner des applications en C, C++ ou pas mal d'autre langage (c'est clair que tu ne vas pas faire tourner les applicatins actuelles ecrites pour des PCs puissant mais ce n'est pas le but, de toute facon de telles applications qui font ce que tu souhaite n'existe certainement pas dans le commerce)

[Mercenary Developer]

Bonjour,

Il me semble qu'avec la dernere version de Borland C++ on peux porter ( pour peut que l'on utilise pas des libs specifique a windows ) du code source C++ de Windows a Linux avec Kylix. De la meme facon que pour Delphi.

Sinon mon grand reproche a Java c'est l'absence des deux fonctions dont je me sert principalement a savoir outp() et inp() pour me permettre de controler des carte ISA "faites maison".

@++

[VisualCBien2]

Si je puis me permettre raisonner de la sorte laisse de cote une bonne partie de l'informatique. Si il est vrai que les PC qui sorte sont tres puissant il ne faut pas oublie le materiel embarque et tout les PCs anciens encore utilise dansl'industrie.

Et on oublie aussi tout les programmes de calculs qui tournent pendant des heures où l'optimisation est essentielle (meme sur un gros calculateur, oui). Là ou C,C++, Camel et Fortran reignent en rois.

Il me semble qu'avec la dernere version de Borland C++ on peux porter ( pour peut que l'on utilise pas des libs specifique a windows ) du code source C++ de Windows a Linux avec Kylix. De la meme facon que pour Delphi.

Le jeune homme n'a pas dit que c'était pas possible :

Cela demande a une attention constante de la part du developpeur

Ce qui est vrai car on a vite fait d'utiliser une macro Windows ou qqchose de pas portable. Et Builder n'est pas le seul à etre multi plateforme.
En C++ t'as le droit d'utiliser des librairies portables (STL, wxWindows...) avec TOUT les éditeurs. Suffit de le configurer.
Mais on va pas partir dans un comparatif editeurs C++, c'est pas le sujet.

[++gib]

Je crois sincerement que C++ surclasse Java en ce qui concerne le developpement logiciel professionnel ( Point de vue de la vitesse (language compilé, pas de Virtual Machine ( moins de resources utilisées), gestion de la mémoire (et oui, c'est TRES souvent tres important) pas de GarbageCollector (Qui sait quand/comment la mémoire est libérée), nombre de fonctions...)

Je pense que c'est tout le contraire :

-> La puissance des machiens actuelle est bien largement suffisante pour compenser. Le seul problème reste le demarage d'une application Java, très lent, car il faut lancer la JVM... Une fois l'application démarrer démarrer, on constate que certain programme Java sont plus rapide que leur homogue en C++ (Saxon est 2x plus rapide que sablotron !)

Très courte vue : Les performances des prgramme Java ne sont tolérables que parcequ'elles bénéficient d'un environnement compilé (en C ou C++) . N'oubions pas que le ratio
en rapidité est d'environ 10 entre Java et C++. Ce chiffre provient de tests réalisés sur des programmes que j'ai ecrits, et non de comparaison de programme X et Y dont on ignore le contenu. Ceci est tellement vrai que toutes les parties critiques du run-time java
(ex: classe String, couches graphiques, et bien d'autres) sont "native", c'est-a-dire codés en C ou C++ !!

Imaginons maintenant un monde informatique parfait (donc codé en Java).
Windows écrit en Java, MFC en java, word en Java, Excel en Java, routeurs réseau et imprimante laser executant un firmware écrit en java, etc...

Ce monde est facile à simuler : Ressortez du grenier le vieux PC 100 ou 200 Mhz et exécutez dessus les programmes d'utilisation courante aujourd'hui.. si vous pouvez.
Vous comprendrez alors votre erreur.

En fait Java ne permet d'ecrire des programmes interessants que parceque ses faibles performances sont compensées par la rapidité des différentes couches logicielles
non-java que ces programmes utilisent. *On peut comparer ce "langage du futur" à un "coucou informatique" parasitant les langages compilés, mais bien incapable de prospérer seul. Ceci ne signifie pas que Java n'ait pas d'intérêt, mais son intérêt est probablement
inférieur à ce que ses zélateurs voudraient faire croire.

-> Tu critique le garbage collector, mais il a au moins l'avantage de liberer la mémoire tot ou tard la memoire, ce qui n'est pas necessairement le cas d'un programme en C++.

Mais ce n'est pas nécessairement PAS le cas ... Ce genre d'argument, que l'on retrouve
partout, instille dans la tête des gens l'idée que les programmes C++ ont TELLEMENT
de chances d'avoir des fuites mémoire qu'ils en ont FORCEMENT. et d'ailleurs, c'est NORMAL si vous programmez en C++ !!!
Revenons sur terre ! La mémoire ne fuit pas par hasard ! La situation est simple :
Fuite de mémoire == programme faux.
Aucun langage ne permet d'exécuter correctement un programme faux, bien que ce soit
le rêve de tous les programmeurs incompétents.
Par ailleurs, un certains nombre d'idées fausses sur l'allocation mémoire ne C++ datent
de C. En utilisant en C++ les conteneurs génériques issus de la STL (Standard Template Library), il n'est pratiquement plus nécessaire de gérer la mémoire. Or ces composants sont STANDARD, très puissants et parfaitement testés.


Le GC est cohérent par rapport aux choix de conception faits dans java. Pas rapide, mais cohérent. Par contre en profiter pour supprimer les destructeurs est a mon sens une
erreur de conception de ce langage.
En effet les gens de chez Sun ont "oublié" que la mémoire n'est pas
la seule ressource à libérer : Il peut y en avoir un millard d'autres (fichier, port, etc) !!
Cette erreur a été compensée par différentes rustines telles que la (fameuse)
fonction finalize() , qui est vraiment le destructeur du pauvre : on ne sait pas à quel
moment elle sera appelée et si on veut en être sur, on doit appeler soi-même
System.runFinalization().
En outre, cette erreur interagit défavorablement avec les exceptions:
réflechissez un peu et vous verrez que l'instruction finalily n'a été créée que pour cela.
(Elle n'est pas nécessaire en C++ car l'appel aux destructeurs des objets locaux a lieu
AUSSI lorsqu'une exception est levée)
En résumé, la conception basée sur la paire (construction/destruction) est claire, efficace, systématique, symétrique. Ellle à été remplacée dans Java par un concept à rustine, semi-manuel, dissymétrique qui a nécessité l'introduction d'une fonction ET d'une instruction suppémentaire.
Du vrai travail de professionnel.

-> Enfin, Un programme Java s'execute dans un envorionnement protégé. Pas de buffer overflow, par d'erreur d'adressage, pas de plantage bete et mechant pour un oui ou un non. Avec un minimum de précaution, on peut assurrer qu'une erreur de codage en Java n'entrainera jamais la mort du programme. En c++, une toute petite erreur de manipulation de pointeur risque a tout moment de remettre ne cause tout l'application.

Gasp, je rêve !!
Je rappelle que les erreurs d'adressage (index incorrect, reference non initialisée)
existent en Java comme dans tous les autres langages. Elles résultent toujours
d'une erreur de programmation. Elle lèvent en Java une exception.
Et ensuite, vous faites quoi ?
Si vous avez installé un gestionnaire d'exception, le programme peut ne pas
planter immédiatement, mais vois continuez sur une situation corrompue, avec des conséquences imprévisibles. Je n'ai jamais vu un programme capable de s'auto-corriger,
juste de sauver les meubles si la cause du problème est identifiable par lui, ce qui est
rarement le cas.
Sinon, le programme s'arrête avec un "stack dump".
Dans tous les cas ... au boulot, que vous le vouliez ou non, l'application
est "remlise en cause" :-)
Je suis etonné du flou de vos propos : c'est quoi une "toute petite erreur de
manipulation sur un pointeur"? (pour moi, elles ont toutes la même taille)

En ce qui concerne la corruption de l'environnement, je rappelle que les systèmes
d'exploitation allouent un espace privé aux programme et que le plantage d'un d'entre eux
ne pertube pas les autres. En tout cas, c'est le cas du mien.
Désolé pour les utilisateurs de Win9x.

-> La portabilité, meme si le C++ est assez facilement portable, cela demande a une attention constante de la pars du developpeur, le prive de bon nombre de bibliotheque ( DirectX, Api Windows, api gnome ou kde...). Resultat, seule les plus grosse application se trouve porté sur windows ET linux, avec souvent un decalage de date pour recodé les fonction plate-forme dependante, si le C++ etait portable, beaucoup d'application typiquement windows serait disponible sous linux, ce n'est pas le cas. Un developpement Java est naturellement portable, sauf action volontaire du programmeur de faire des appels systeme.

Ne mélangeons pas tout
1) portabilité du langage
2) disponibilité des bibliothèques
3) Intérêt économique du portage

1) Bien que non parfaite, la portabilité du langage C++ est très grande.
Les points de non-portabilité sont bien connus il est facile de les éviter.. Si on le désire.
La quantité de code commun a diverses plate-forme est absolument énorme, bien que le
grand public n'en ait pas toujours conscience.
Une évidence oubliée est que la portabilité de Java n'existe (via la Machine virtuelle)
que parcequ'elle est écrite dans un langage lui-même portable : C ou C++. CQFD.

2) Ici, c'est la grande confusion. Beaucoup de fonctionnalités (ex: graphique) sont
attribuées à un langage alors qu'elles dependent d'une bibliothèque.
Il existe énormément de bibliothèques permettant de retrouver les memes fonctionnalités
sur des environnements différents.
Je recommande d'utiliser Qt , qui est (entre autres) un environnement graphique de
TRES HAUTE qualité (base de KDE) utilisable sous Unix/Windows et Mac !!
http://www.trolltech.com/
De plus il est gratuit pour les appli non commerciales.

Que demander de mieux !

3) Certaines application ne sont pas portées par manque d'intérêt économique
tout simplement : lorsqu'on a 95% du marché sous la main, pourquoi lever le petit
doigt pour toucher le reste ?

Bon pour terminer .. il existe des programmeurs Java qui rendent VOLONTAIREMENT leur programmes non-portables ? Tss Tss !!

[gl]

Pour revenir a la question de portabilite de Java, je voudrais juste signaler qu'on commence a trouver Java sur du materiel autre qu'ordinateur (carte a puce, tele numerique, etc) et que le byte genere n'est pas toujours compatible avec celui genere par du PC (bien souvent meme les sources ne sont pas portable) car pour des soucis de performances, certains couches non utilise ont ete supprimer, des partie de code sont compile en natif, etc.
Le Java est certes un modele de portabilite tant que l'on reste sur du materiel classique mais des que l'on sors des sentiers battus ce n'est plus vrai

[gregy]

++Gib , tu as tout dit !!! Bravo! je n'ai jamais vu autant de bétises par rapport à java. Je ne crois meme pas que ca vaille la peine de decortiquer tout ton tissus de désinformation tellement que ca va loin... (je crois même pas que ce débat vaille la peine d'etre continué, ainsi que tout les autres qui causent des performances d'un langage p/r à un autre, vu toute la subjectivité qu'on peut y retrouver...)

[++gib]

++Gib , tu as tout dit !!! Bravo! je n'ai jamais vu autant de bétises par rapport à java. Je ne crois meme pas que ca vaille la peine de decortiquer tout ton tissus de désinformation tellement que ca va loin...

Mmmm, ça risque sutout d'être difficile. Les faits sont têtus, et une argumentation technique
est difficile à réfuter.

(je crois même pas que ce débat vaille la peine d'etre continué, ainsi que tout les autres qui
causent des performances d'un langage p/r à un autre, vu toute la subjectivité qu'on peut y
retrouver...)

Une mesure à un sens -objectif- à partir du moment ou l'on sait ce que l'on mesure.
En l'occurence il s'agit du temps mis à exécuter un code connu. Je peux d'ailleurs le résultat
de la mesure et le code concerné, de façon à ce que chacun puisse reproduire l'expérience
dans son environnement.

[++gib]

Dans l'ensemble tu as mal pris mon propos. Je n'ai jamais dis que Java etait un langage ultime, bon a tout faire...

Hélas, le lancement marketing de Java par Sun à été si bien fait dès le début
que beaucoup le croient.

On ne va pas faire une bataille de chiffre, mais la performance des JVMs croit à chaque version. La performance du GC aussi. Les programmes Java sont compilé/optimisé à la volé. Bref se fameux ratio a tendance a diminuer.

Demain, on rase gratis.
C'est un argument que j'entends depuis l'arrivée de Java, et qui n'a jamais été réellement
confirmé par les faits. On joue sur quelques dizaines de %.
En examinant de près le fonctionnement de la MV, (GC, gestion du méta-modèle des classes, authentification du code, interprétation du Byte-Code, etc..), il est déja remarquable
que les performances soient ce qu'elles sont.
D'ailleurs, je teste régulièrement l'implémentation de Sun depuis des années,
et je n'ai pas constaté de différence réellement probante. Alors on en arrive doucement
à compiler. Manque de chance, Java compilé perd de son charme et le byte-code
de son éclat : où est passée la fameuse interopérabilité du code ?
Les navigateurs WEB sont déjà deux fois plus gros qu'ils ne devraient l'être à cause de la
nécessité d'emabarquer une machine virtuelle (et sa pléthore de données), voici maintenant
qu'ils devront aussi comporter un compilateur optimisant pour exécuter une applet de
quatre sous.
Reconnaissez tout de même que l'approche prête le flanc à la critique.

Bien sur que les parti critique sont ecrite en C++, comme c'est le cas de tous les langages interpreté. Tu ne vas pas demander a python, perl, bash de decrire eux meme leur structure de donnée interne, ca n'a aucun sens.

Cais ces langages n'ont jamais prétendu être autre chose
que ce qu'ils sont : des langages de script à usage bien défini et non des langages généralistes.

En ce qui concerne la capacité d'auto-écriture, bien sûr que si ça a un sens,
c'est justement grâce à ça que C est devenu ce qu'il est devenu et qu'il existe
sur toutes les plate-formes, et pour tous les processeurs. C'est aussi ce qui
a permis la diffusion d'UNIX etc ... Revoyez l'histoire.
Que serait il arrivé si C avait été écrit avec un des langages des années 70
(par exemple FORTRAN) ?

Ce n'est pas mon propos, ce n'est pas ma definition d'un monde parfait... Tu parle d'imprimante laser embarquant du Java ? je n'ose te dire que Java a été concus pour etre facilement embarquer dans les systemes (téléphone et autre)

Oui, je connais moi aussi l'histoire de Java/Oak. Le firmware de machine à laver était
sa destination première, et ça a été un echec commercial. La dessus, internet est
arrivé et ça a sauvé le langage en lui offrant un débouché. On n'a plus entendu parler de
ce type d'application pendant au moins 5 ans, et ça revient maintenant, avec des
restrictions qui font que ce n'est pas le Java dont nous parlons qui est utilisé, mais quelque
chose de beaucoup plus réduit.
(voir c-dessus le post de gl du 21 janvier qui résume la situation)

Je n'ai pas dis qu'une erreur de conception était corriger... elle est ratrappé et traité. C'est sur que si c'est le code de chargement de l'appli, ou une fonction de base qui plante systématiquement, on ne peut rien faire de plus que de corriger le programme. En revanche, s'il saggit d'une fonction annexe, pratique sans être vital, on peut continuer l'execution sans risque (Une petite sauvegarde automatique tout de meme). C'est pas par ce que la fonction de correction orthographique de word ne marche pas que tu doit planter, renvoyer l'utilisateur en criant "FATAL ERROR" ... C'est pas pasque l'assistant d'aide automatique (le fameux trombone d'office) refuse de s'executer que tu ne peux pas continuer a travailler !

Je vois bien la philosophie générale, mais prétendre que l'on peut "continuer sans risque" me
semble osé. Mon expérience des bugs est qu'ils peuvent produire n'importe quoi, y
compris la sauvegarde de données vérolées. Si on part dans ce genre de codage
pseudo-pragmatique à court terme, autant émigrer à Redmond, la patrie du trombone.
On ne peut traiter efficacement une exception que si elle correspond à quelque
chose de prévu. Le bug est par définition imprévu (sinon le code serait correct).
Dans ce cas, à part traiter par le mépris : ( catch(Exception e) {} ),
(ce qui peut être pire qu'un simple plantage) on ne peut rien faire.

Un programme qui "rattrape une erreur de conception" c'est une trouvaille.
Si ça existait, il n'y aurait plus de programmeurs depuis longtemps.

J'insite: Les exceptions (puisqu'on parle de ça) sont un outil de centralisation pour le
traitement délocalisé de situations anormales mais prévues. (exemple on attend un entier,
de la part de l'utilisateur, on reçoit la chaine "toto")
Pas une rustine pour gérer les bugs ! Dans ce cadre, ça ne sert à rien.

La seule façon raisonnable et immédiate de se débrouiller avec une fonctionnalité
buggée est (je crois) de ne pas l'utiliser.

[Clement Cunin]

Alors on en arrive doucement
à compiler. Manque de chance, Java compilé perd de son charme et le byte-code
de son éclat : où est passée la fameuse interopérabilité du code ?

Tu n'as rien compris, le code distribuer est toujours le bytecode, mais lors du chargement, on compile en natif (c'est donc la JVM qui compile !) ainsi on cumule les avantages du code natif (en temps) et du bytecode pour l'independance a la machine.

voici maintenant
qu'ils devront aussi comporter un compilateur optimisant pour exécuter une applet de
quatre sous.

Mince alors, quand tu pense qu'un compilo s'ecrit en moins de 1Mo...
IE full : 80 Mo
Windows XP 1.5Go juste apres install...
C'est sur qu'avec ca c'est pas sur qu'il te reste 1Mo !
Meme avec ces boulets, je reconnais au C tous les avantage qu'il merite

En ce qui concerne la capacité d'auto-écriture, bien sûr que si ça a un sens,
c'est justement grâce à ça que C est devenu ce qu'il est devenu et qu'il existe
sur toutes les plate-formes, et pour tous les processeurs.

Biens sur, Le C est a été fait pour prendre un peu de distance avec la machine, mais pas trop...
La meilleur réussite du C : le type int, des fois 2octets, des fois 4, au petit bonheur la chance !!!
Le C n'est pas parfait, Java non plus, mais il ont tout 2 des aspect interressant !


Maintenant, la gestion des erreurs. Je sais pas ce qu'elles t'ont fait les exceptions, mais ca semble te poser un sacré problème. Peut-etre tout simplement parce qu'elle permete des chose inimaginable en C.
Pour moi, un logiciel professionnel est un logiciel qui ne plante pas, donc sans erreur, super nickel sous tout rapport. L'informatique nous a rapidement appris a relativisé cet etat de fait. On ne pas JAMAIS prouver qu'un logiciel est juste... Donc on peut toujours considerer qu'il reste une ou 2 erreurs quelque part. Jusque la, je pense que tout le monde sera d'accords !
En C / C++, lorsqu'il y a une erreur, le plus souvent c'est trop tard, tu as ecrit en memoire la ou tu n'aurais pas dut, ecrasant un peu n'importe quoi... Bref, quand ca pars mal, tu ne peux rien faire...
En Java, si tu execute une fonction et qu'elle te reponds NullPointerException, tu sais exactement quel partie du code a buggé, si tu leve les yeux, tu peux aussi savoir quel sont les données auxquel cette fonction avait acces... Donc tu peux savoir assez precisement ce qui est probablement corrompus et identifier ce qui ne l'ai pas !

Dans ce cas, à part traiter par le mépris : ( catch(Exception e) {} ),
(ce qui peut être pire qu'un simple plantage) on ne peut rien faire.

Le catch n'est pas la fin du traitement d'une exception, c'est le debut.

C'est sûr que si tu code n'importe comment, ca marche pas, la dessus on est tous d'accords.

Un programme qui "rattrape une erreur de conception" c'est une trouvaille.

Non, ca n'existe pas, et ca n'existera jamais, ca a été demontrer mathematiquement !
Le but est juste qu'une petite erreur d'implementation n'entraine pas une vrai catastrophe !
(D'ailleur les ingenieurs qui ont programmer la premiere ariane 5 aurais été avisé de tenir compte de l'exception généré par le programme (ADA))

J'insiste aussi : Ne maiprise pas quelle que chose que tu ne maitrise pas !

[gregy]

J'insiste aussi : Ne maiprise pas quelle que chose que tu ne maitrise pas !

Il y a au moins une chose qu'il maitrise : c'est la désinformation... je ne sais pas d'où tu tiens tes sources ++gib mais t'es à côté de la plaque sur beacoups de points.

A t'entendre ++gib, java n'aurait pas plus de valeur qu'un langage tel que javascript ou autre langage(de script) 'limité'. Pour information je travailles sur tres grosse appli en java. Les appli sont compilées, donc je confirme ce que dit Clément, c'est bien à partir du bytecode que l'on compile. Est-ce un probleme p/r à la portabilité??? rien du tout. Ton code(bytecode) reste portable sur une autre machine. A ce que je sache un *.exe windows écrit en C/C++ et avec un code portable ne tournera pas sous linux, il faut le recompiler ... Donc à partir du moment où il y a un compilo disponible sur le systeme, ton code est portable et il y a moyen d'avoir un executable natif.

D'un autre côté, quand je lit les messages, le theme recurant, c'est les performances de java sur des anciennes machines. Certes, c/c++ aura plus de performances sur ces machines. Mais il faudrait peut-être parler d'appli actuelles avec des machines actuelles! On ne parle pas d'une aplli qui affiche 100 fois 'Bonjour le monde' sur un 60Mhz... Certainement que c/c++ sera plus performant pour des applications orientées systeme ou de calculs, mais je doute sur des plus grandes performances sur des appli de gestion... Et les appli des gestion (actuelles), ca ne tourne pas sur un 60 Mgz avec 32 Mg de ram! Le reste c'est qu'une question du choix de langage. Je ne dit pas que java est le meilleur langage, chacun a ses defauts et atouts, mais la 'facilité' de programmation fait parti des questions que l'on se pose lorsque l'on débute un projet. Et à contrario de ce que je peut lire, java n'est pas un langage 'si' facile à utiliser (souvent mal utilisé), mais facilite énormément le travail p/r à C/C++...

Aute chose, j'ai parfois l'impression que java est associé avec 'Applet'... Pour ma part je n'ai pas franchement l'impression que java fait son cheval de bataille avec les applets. D'ailleurs je ne voit que tres peut de sites qui utilisent des applets. De dire qu'on doive optimiser de browser pour faire tourner une applet ' à 4 sous ' c'est completement faux! Juste pour exemple: IE6 n'integre plus la JVM (de sun)(et si on parle de netscape, malheureusement c'est écrit 100% en java dans ses versions actuelles, mais bon je suis sur que personne n'utilise ces browsers là). S'il faut la télécharger c'est 5meg voir 10 meg ... Evidemment on va me dire c'est pas de bol pour les gens qui ont un p1 60 Mgz avec un modem 13600...

Je trouves également un peu stupide de critiquer java pour sa philosphie de langage. Notament le fameux try catch dont l'existance, il me semble, existe egalement en c++. Oui sans doute c'est le c++ de M$, mais je crois qu'en c++ ils ont une bonne part de marché... Alors critiquer java pour ca, et que ca existe dans une des grandes distribution de C++, ... Crtitiquer java pour le gc, on peut critiquer c/c++ car il y a un très grand nombre de programmeurs dans ces langages qui gerent tres mal les ponteurs. Java ne libere pas les ports, fichiers? ... ben effectivement, un fichier ca se ferme, comme dans tous les langages (je ne crois pas que c/C++ en face exception). Rien ne t'empeche en java d'implementer un type de fichier qui se ferme à sa destruction par la gc (OUI dans la méthode 'finalize'). Dire que la méthode finalize est une rustine ??? Je comprends pas trop... Le destructeur en c++ en est-elle une??? Le finally (try/catch/finally)est un rustine ??? je ne trouves pas du tout, c'est vraiment tres utile (Mais bon on m'affirme que les destructeurs C++ sont tellement performants qu'ils se declanchent automatiquement quand il y a une exception)

Alors, pour terminer, oui c/c++ a certainement plus de performances dans l'absolue. Mais il faudrait également tenir en compte le temps de developpement, la ' facilité' de programmation, et les technologies actuelles... Contrairement à ce que certains disent java permet de faire énorment de projets dans bcp de domaines...N'oublions pas non plus que java n' a pas plus de 10 ans d'âge et connait un tres grand succes (et ce n'est pas par HASARD, ni par COUP DE PUB!) et va continuer à évoluer ...

[++gib]

[quote]

J'insiste aussi : Ne maiprise pas quelle que chose que tu ne maitrise pas !

Il y a au moins une chose qu'il maitrise : c'est la désinformation... je ne sais pas d'où tu tiens tes sources ++gib mais t'es à côté de la plaque sur beacoups de points.

Facile: j'observe, je mesure, je vais voir le code lorsque j'en ai l'occasion
et je considère les annonces des différents acteurs avec circonspection.
Dans l'ambiance générale commerciale, ça aide à prendre du recul.
Lorsque j'avance que j'ai mesuré des performances médiocres, je n'ai pas
besoin d'autres sources que celle de mon expérience.

A t'entendre ++gib, java n'aurait pas plus de valeur qu'un langage tel que javascript ou autre langage(de script) 'limité'. Pour information je travailles sur tres grosse appli en java. Les appli sont compilées, donc je confirme ce que dit Clément, c'est bien à partir du bytecode que l'on compile. Est-ce un probleme p/r à la portabilité??? rien du tout.

Je vais donc en profiter pour faire une réponse à vous deux. C'est gentil
d'avancer que je n'ai rien compris et je n'ai pas besoin de votre confirmation
pour savoir que c'est effectivement le byte-code qui est compilé. Ca ne change rien au fait que pour compiler vers une machine cible, on doit
générer du code spécifique à celle ci (techniquement: pour cela, la partie
arrière du compilateur doit être spécifique). On retombe donc bien dans
une problématique de compilation, avec développement de la partie arrière
du compilateur pour chaque cible et les aléas liés à ce genre d'opération.
En effet, si la portabilité de la VM est garantie par le langage dans lequel
elle est rédigée (C par exemple), la génération de code objet spécifique à un
processeur est une opération nettement plus difficile à rendre portable (et le
fait que le compilateur s'exécute sous la VM n'y change rien, n'en dépaise à Clément).
Comprenez moi bien : Ce n'est pas plus ardu que de développer et de
déployer que n'importe quel compilateur, mais le le slogan "Développez une fois,
déployez partout" après ça, c'est de la promesse électorale.

Il y a un autre phénomène qui réduit les performances de l'approche :
Le programme résultant doit évidemment permettre ce que Java permet
(introspection du méta-modèle objet, GC, vérification de type à l'exécution,
etc.) Il est donc très probable (et souhaitable pour la sureté)
que la VM (ou des extraits de celle-ci) garde à sa charge ces opérations.
Nous avons donc uniquement gagné le temps d'interprétation du byte-code.
Je me souviens avoir testé les performances de code Java compilé :
à l'époque (3 ou 4 ans) les gains n'était pas fameux, en tout cas loin
de ce qu'on obtient ordinairement d'une approche compilée.

Ton code(bytecode) reste portable sur une autre machine. A ce que je sache un *.exe windows écrit en C/C++ et avec un code portable ne tournera pas sous linux, il faut le recompiler ... Donc à partir du moment où il y a un compilo disponible sur le systeme, ton code est portable et il y a moyen d'avoir un executable natif.

Vous l'avez dit, c'est pareil si on compile le byte-code.
Donc pourquoi utiliser quelque chose de lent ?
Le byte-code dans l'approche traditionnelle Java
est plus que portable : il est également (théoriquement) inter-opérable
on perd cette qualité en compilant. Reste à évaluer si le gain qu'on
obtient en échange est intéressant. Ca, c'est à juger au coup par coup.

D'un autre côté, quand je lit les messages, le theme recurant, c'est les performances de java sur des anciennes machines. Certes, c/c++ aura plus de performances sur ces machines. Mais il faudrait peut-être parler d'appli actuelles avec des machines actuelles! On ne parle pas d'une aplli qui affiche 100 fois 'Bonjour le monde' sur un 60Mhz... Certainement que c/c++ sera plus performant pour des applications orientées systeme ou de calculs, mais je doute sur des plus grandes performances sur des appli de gestion... Et les appli des gestion (actuelles), ca ne tourne pas sur un 60 Mgz avec 32 Mg de ram!

Ah non !! Sur TOUTES les machines même les plus modernes.
Il se trouve que se qui est supportable sur un P4-1Ghz aurait été insupportable sur un 386-60Mhz, mais ce qui est important c'est de comprendre que l'on perd
90% des ressources processeur sur du code Java. Cela ne marche que si on n'exécute qu'un très petit nombre de programmes Java à l'instant t.
Java tient la route. Il tient même toute la route.
En outre les performances de Java n'ont rien à voir avec les domaines d'application, mais avec son mode d'exécution.

Le reste c'est qu'une question du choix de langage. Je ne dit pas que java est le meilleur langage, chacun a ses defauts et atouts, mais la 'facilité' de programmation fait parti des questions que l'on se pose lorsque l'on débute un projet. Et à contrario de ce que je peut lire, java n'est pas un langage 'si' facile à utiliser (souvent mal utilisé), mais facilite énormément le travail p/r à C/C++...

Là je n'ai rien à objecter. D'abord parceque c'est une question de goût
personnel, mais aussi parceque je le trouve aussi assez facile. Pourtant
je préfère programmer en C++ car ça me permet d'aller plus loin, avec plus d'élégance et
parceque le résultat est plus efficace. C'est la peinture à
l'huile contre la peinture à l'eau.
Mais le jour ou j'aurai besoin de transporter du code inter-opérable,
Java est le meilleur choix.

Aute chose, j'ai parfois l'impression que java est associé avec 'Applet'... Pour ma part je n'ai pas franchement l'impression que java fait son cheval de bataille avec les applets.

Compte tenu de la philosophie du langage, ça devrait être idéal. J'en ai écrit une il y a peu. Sur 5 navigateurs testés (sur 2 machines),
j'ai obtenu 4 résultats différents.
En fait, seul "appletviewer" de sun me donne exactement ce que je souhaite.
Bon mon code est peut-etre pourri, et les navigateurs n'y sont peut être
pas pour rien mais tout de même ... ceci explique peut être cela.

Je trouves également un peu stupide de critiquer java pour sa philosphie de langage.

Certainement, à partir du moment ou elle est cohérente, il n'y a pas a
critiquer, mais utiliser le langage là ou il est performant.
[quote]

Notament le fameux try catch dont l'existance, il me semble, existe egalement en c++. Oui sans doute c'est le c++ de M$, mais je crois qu'en c++ ils ont une bonne part de marché... Alors critiquer java pour ca, et que ca existe dans une des grandes distribution de C++, ... Crtitiquer java pour le gc, on peut critiquer c/c++ car il y a un très grand nombre de programmeurs dans ces langages qui gerent tres mal les ponteurs. Java ne libere pas les ports, fichiers? ... ben effectivement, un fichier ca se ferme, comme dans tous les langages (je ne crois pas que c/C++ en face exception). Rien ne t'empeche en java d'implementer un type de fichier qui se ferme à sa destruction par la gc (OUI dans la méthode 'finalize'). Dire que la méthode finalize est une rustine ??? Je comprends pas trop... Le destructeur en c++ en est-elle une??? Le finally (try/catch/finally)est un rustine ??? je ne trouves pas du tout, c'est vraiment tres utile (Mais bon on m'affirme que les destructeurs C++ sont tellement performants qu'ils se declanchent automatiquement quand il y a une exception)

Je ne critique pas try/catch (qui est au poil) mais son utilisation pour récupérer les bugs. Je développerai ceci plus tard dans une réponse à Clément.

Enormément de programmeurs paniquent à la vue des pointeurs et avec l'allocation dynamique. J'ai d'ailleurs observé que c'est ceux-là qui ont filé
vers Java au début...encouragés par la pub de Sun. Sont-ils devenus
bons pour autant ?

finalize() a un défaut, elle est appelée a un moment indéterminé
(éventuellement jamais). En pratique, elle est souvent appelée "très vite",
mais ceci ne suffit pas si on contrôle certains équipements ou
structures de données dont on à besoin de connaître l'état exact à
l'instant t (exemple : carte son, port //, base de données,...)
Le destructeur C++ est appelé lorsque l'objet sort de sa portée (la zone
dans laquelle il est connu, généralement matérialisée par {})
Comportement systématique, donc prévisible.
C'est pour cela que je défend l'idée que Sun aurait du garder la notion de
destructeur (en plus du GC, qui, je le répète est cohérent).
Je suis ouvert à toute discussion technique sur le sujet.

Pourquoi finally est une rustine ? Parcequ'elle a pour but de
rattrapper le defaut précédent. Lorsqu'une exception est lancée en C++
les objets locaux à la méthode sortent de leur portée, ils sont donc déalloués
et leur destructeur est exécuté. Ce destructeur est donc un endroit naturel
pour liberer des ressources locales à la fonction, quel qu'elles soient.
C'est la mise en oeuvre du principe "la construction est une allocation
de ressource" (donc la destruction est une restitution).

En Java, seule la ressource mémoire est libérée automatiquement. Pour le
reste on doit le confier a un bloc finally ou à à finalize()
dont on connait l'inconvénient.
Je peux vous fournir un exemple C++/Java qui montre cela.

Sun a replacé quelque chose de clean par autre chose d'inutilement compliqué
et de moins efficace.

Alors, pour terminer, oui c/c++ a certainement plus de performances dans l'absolue. Mais il faudrait également tenir en compte le temps de developpement, la ' facilité' de programmation, et les technologies actuelles... Contrairement à ce que certains disent java permet de faire énorment de projets dans bcp de domaines...N'oublions pas non plus que java n' a pas plus de 10 ans d'âge et connait un tres grand succes (et ce n'est pas par HASARD, ni par COUP DE PUB!) et va continuer à évoluer ...

Effectivement, ce coup de pub n'est pas un hasard. Java a très vite trouvé le
public de ceux pour qui la facilité de développement compte plus
que le résultat.

Pour le reste, on pourrait en dire autant de tous les langages.

[Clement Cunin]

Bon, je constate que tu n'as pas compris le fonctionnement d'un JIT.

Le programme java est distribuer en bytecode. Lorsque que l'utilisateur souhaite executer ce programme, il utilise une JVM (qui est depends de sa plateforme). Cette JVM inclus un JIT (qui depends egalement de la plateforme) dont le but est d'optimiser et de compiler en natif les sections critiques du programme pendans l'execution (ou pendant le chargement).
Il n'y a aucune restriction de portabilité la dedans !

Maintenant je te propose d'aborder 2 concepte qui font la force de Java comparer au C++.
-> Le chargement dynamique.
-> Les threads.

Le chargement dynamique, même s'il entraine un coût en ressource non negligeable a de nombreux avantage.
- Permettre par example de commencer l'execution d'une applet alors que seulement 10% du code n'est telecharger. Je ne connais aucun mecanisme simple equivalent en C++.
- Permet de developpez des programmes modulaires de facon tres tres facile. Developper un systeme de plug'in pour une application java est d'une simplicité deconcertante. En 3 lignes de code tu charge et execute ton plug'in.

En Java, les threads sont implementé au coeur de la JVM, c'est tellement simple de les faire communiquer que tu comprends a peine que des gens continue à se faire chier avec des semaphores, des pipes, des mémoires partagés ...

Depuis le debut tu critique les performances de Java, sans veritable comprendre les raisons de cette perte de performance. Le code interpreté n'est pas a lui seul responsable de cette perte de performance, et c'est probablement pas le plus gros problème de Java.
Java n'est pas parfait, loin s'en faut, mais tu n'as toujours pas mis le doigt sur les vrai problème du langage, sur les vrais erreurs de conception.
D'ailleurs, rare sont les personnes qui attaquent Java en connaissant vraiment le langage.

[++gib]

Alors on en arrive doucement
à compiler. Manque de chance, Java compilé perd de son charme et le byte-code
de son éclat : où est passée la fameuse interopérabilité du code ?

Tu n'as rien compris, le code distribuer est toujours le bytecode, mais lors du chargement, on compile en natif (c'est donc la JVM qui compile !) ainsi on cumule les avantages du code natif (en temps) et du bytecode pour l'independance a la machine.

Voir réponse à greggy.

Mince alors, quand tu pense qu'un compilo s'ecrit en moins de 1Mo...
IE full : 80 Mo
Windows XP 1.5Go juste apres install...
C'est sur qu'avec ca c'est pas sur qu'il te reste 1Mo !
Meme avec ces boulets, je reconnais au C tous les avantage qu'il merite

Raison de plus de ne pas en remettre une couche si ce n'est pas nécessaire.
En outre la taille de l'exécutable n'a pas grand chose à voir avec
ce que le programme va prendre à l'exécution. Certains prgm gènèrent
une quantité de données impressionnante.

Biens sur, Le C est a été fait pour prendre un peu de distance avec la machine, mais pas trop...
La meilleur réussite du C : le type int, des fois 2octets, des fois 4, au petit bonheur la chance !!!
Le C n'est pas parfait, Java non plus, mais il ont tout 2 des aspect interressant !

Ce type d'aspect est certainement frustrant pour le programmeur.
Le type int est défini comme étant l'entier "naturel" du processeur
cible, pour des raisons d'efficacité.
Il est donc cohérent qu'il soit à géométrie variable. Il est certes
plus confortable de décréter que tous les entiers sont sur 32 bits
et de travailler sur un processeur virtuel.
Sa conception a au moins permis au C de traverser les décennies
en s'adaptant aux diverses générations de processeurs :
16,32,64 et bientôt le int 128 bits ;-)
Pour les inquiets, assert(sizeof(int) == 4); devrait le faire.
Attention, ceci est moins anodin qu'il n'y parait : que deviendra la
machine virtuelle lorsque qu'elle sera rétrograde par rapport à la
technologie ? Elle va évoluer (je lui souhaite) et on aura les mêmes
problèmes qu'avec les processeurs physiques. Dèjà on murmure qu'on
aurait mieux fait de coder le char sur 32 au lieu de 16 bits car des
versions d'unicode ne rentrent plus dedans.
La généricité rendrait des services dans ce domaine là aussi.

Maintenant, la gestion des erreurs. Je sais pas ce qu'elles t'ont fait les exceptions, mais ca semble te poser un sacré problème. Peut-etre tout simplement parce qu'elle permete des chose inimaginable en C.

Attention, ceci est un forum C++/Java. Pas d'amalgame, ceci est trop courant
et trop facile. Je pourrais par exemple critiquer Java en parlant de javascript,
ce qui ne serait pas malin. Le modèle d'excepion de C++ est très
proche de celui de Java et les exception ne me posent pas le moindre problème.
Les gens qui les utilisent sans les comprendre, si.
D'autre part, je ne prend pas C pour autre chose
que ce qu'il est : un assembleur d'une qualité inégalée.

Pour moi, un logiciel professionnel est un logiciel qui ne plante pas, donc sans erreur, super nickel sous tout rapport. L'informatique nous a rapidement appris a relativisé cet etat de fait. On ne pas JAMAIS prouver qu'un logiciel est juste... Donc on peut toujours considerer qu'il reste une ou 2 erreurs quelque part. Jusque la, je pense que tout le monde sera d'accords !

Absolument.

En C / C++, lorsqu'il y a une erreur, le plus souvent c'est trop tard, tu as ecrit en memoire la ou tu n'aurais pas dut, ecrasant un peu n'importe quoi... Bref, quand ca pars mal, tu ne peux rien faire...
En Java, si tu execute une fonction et qu'elle te reponds NullPointerException, tu sais exactement quel partie du code a buggé, si tu leve les yeux, tu peux aussi savoir quel sont les données auxquel cette fonction avait acces... Donc tu peux savoir assez precisement ce qui est probablement corrompus et identifier ce qui ne l'ai pas !

J'ai peur de ne pas comprendre. Vous parlez du comportement du programmeur
ou de celui du programme ?
Dans le premier cas, si un prgm plante, un debugger moyen est capable de dire
où et pourquoi. La cause réelle initiale peut se situer très loin,
mais c'est toujours le cas en programmation. Ca peut demander
beaucoup de réflexion.
Dans l'autre cas, il est assez osé de prétendre pouvoir analyser
par programme la cause réelle d'une exception, sutout si elle est
aussi générale que NullPointerException LORSQUE CELLE-CI PROVIENT D'UN BUG.

(j'en profite au passage pour signaler que le langage-sans-pointeur
vient de faire la preuve qu'il est bien difficile de s'en passer).

Reprenons.
Les gestionnaires ne peuvent êtres écrits que pour gérer des situations
anormales, mais prévues, le reste est du bricolage car par définition
le bug est imprévu sinon il ne serait pas là.
C'est simple: les exceptions ne sont pas faites pour traiter les bugs
et elles sont inefficaces dans ce cas.
Lorsque votre indice de tableau est
sorti des limites, certes vous n'êtes pas allé "taper" dans les données
alentours mais qui peut dire ce qui s'est passé avant ? Pourquoi est il
sorti ? Avant de provoquer une erreur physique, le bug a très bien
pu provoquer des erreurs logiques. Le seul intérêt dans ce cadre
est de ne pas aller casser les autres applications, mais cela un OS
digne de ce nom muni d'un MMU le fait très bien aussi.
Compter sur les exceptions pour réparer ce genre de situation n'est
pas simplement irréaliste, c'est dangereux car ça induit une impression
(fausse) de sécurité dans la tête du programmeur.
En tout cas, j'ai subi il y a peu un plantage d'applet et je peux dire
qu'en temps qu'utilisateur, avoir un "stack dump" et le nom de l'exception
n'a pas diminué ma frustration. J'aurais préféré que le programmeur fasse
son boulot, intercepte l'exception et la traite. Mais le pouvait il ?
(C'était un pb de chargement de classe).

L'intérêt des exceptions est de centraliser les traitements
de situations anormales mais prévues et
d'éviter d'entrelacer le code utile avec des tests nécessaires
mais improductifs .. lorsque tout va bien. DANS CE CADRE, ça permet
de rendre le code plus clean et d'éviter un plantage, en Java comme en C++.

Le but est juste qu'une petite erreur d'implementation n'entraine pas une vrai catastrophe !
(D'ailleur les ingenieurs qui ont programmer la premiere ariane 5 aurais été avisé de tenir compte de l'exception généré par le programme (ADA))

La plus petite erreur d'implémentation mesure exactement 1 bit : elle
est potentiellement aussi dangereuse que les autres. Je crois avoir
assez dit ce que je pensais de l'usage des exceptions dans ce cadre
et je vais être bref: c'est du hack.

Je ne connais pas le détail du bug d'ARIANE V. Puis-je en savoir plus ?

J'insiste aussi : Ne maiprise pas quelle que chose que tu ne maitrise pas !

Hum... De quelle chose s'agit-il ?

[Clement Cunin]

Tout cela est bien pathétique.

je pourrais par exemple critiquer Java en parlant de javascript

Prouvant encore une fois que tu n'y connait rien a Java et javascript...
Le C++ est la couche object du C
Le javascript n'a strictement rien a voir avec le langage Java.


On peux faire 2 choses avec les exceptions :
-> rattrage d'erreur previsible. Ca on est tous d'accords, c'est faisable en C++
-> rattrape d'erreur imprévus, c'est possible en Java, mais pas en C++.
Le but étant, APRES deployement, d'essayer si possible, de palier une erreur de conception qui aurait echappé au phase de test de developpement. Tu sais, le jours ou tu dis que normalement tous marche, que tu vens ton programme, et que malgrés tout tes effort il reste une merde dedans.
Le but n'est pas d'afficher une trace d'execution dans une fenetre, mais de determiner un gros quel parti du programme a causé une erreur pour dire a l'utilisateur que tel ou tel fonction n'a pas marcher correctement.


Voila l'histoire d'Ariane 5.
Les ingenieurs en chargent du programme de guidage embarqué de la fusée sont parti du programme et du module de test d'Ariane 4. Ils ont ensuite adapté le programme et le jeu de test à la nouvelle fusée.
L'ordinateur de bord à la charge de controler plusieurs modules, la trajectoire, le niveau de carburant, le comportement physique... lors des simulations, le programme c'est bien comporté. Mais lors du lancement, un des modules a généré une erreur les ingenieurs n'avait prevus cette erreur, ils n'ont pas tenu compte des exceptions, tous le programme s'est bloqué entrainant la destruction d'une fusé a plusieurs millions d'euros.
Si l'erreur avait été traité au plus tot, le module arait pus etre qualifié d'instable, desactivé proprement, laissant le soin au ingénieur au sol de géré eux même ce module. Ce module n'etait pas nécéssairement critique pour le succes de la mission.

Exactement comme un bug dans le correcteur orthographique de word ne DOIT PAS t'empecher d'imprimé un rapport a rendre le lendemain !!!!

Pour Ariane, les ingénieurs avaient simplement oublié d'adapter un paramètre lors du passage de Ariane 4 à 5 .... Le jeux de test etait erroné, ca fait cher l'erreur !

L'isolation des données à l'intérieur d'un même programme releve du défit en C++. La combinaisons des Threads, de l'environnement protégé, permettent des choses impossible en C/C++.

[laffreuxthomas]

++gib, tu penses connaitre Java car tu as testé de tout petits programmes écrit en Java contre leur équivalent en C++.

Ca ne fait pas de toi un développeur Java, je peux t'affirmer que tu ne connais pas cette plate-forme.

Tu me fais penser à une amie américaine qui vit en France en ce moment. Elle voit toutes les petites manies bien françaises avec ses yeux d'américaine et ça la dégoute. Elle refuse de s'intégrer et donc de comprendre.

Je suis certain que tu as un bon niveau technique en système et que tu piges les traitements sous-jacents des langages. Tu as peut-être aussi une bonne culture Objet. Le langage C++ est Objet et le code machine qui en est issu est performant.

Mais si tu veux comprendre l'intérêt du Java, alors prend un projet pour lequel tu estimes que C++ serait adapté, et réalise le en Java. Et fais-le à la manière Java, sans chercher à l'optimiser en fonction du bytecode généré, seulement en pensant Objet.

Sinon des limitations au niveau syntaxique en Java il y en a. Il suffit de connaitre un peu C# pour les comprendre. Mais elles ne sont pas dans tes critiques.

Thomas

[gregy]

Raison de plus de ne pas en remettre une couche si ce n'est pas nécessaire.

Comme déjà dit, les jvm ne sont plus pris en charge par les/certains browsers. C'est pris en charge sous forme de plug-in comme le sont pris flash ou autres. Alors si les applets, flash's ou autres 'programmes' interactifs sur le net t'ennuient, et bien ne télécharge pas les plug-in's ... c'est jusque là! Si tu n'arrive à programmer que des choses médiocres en applet java, ca ne reste que ton probleme, moi je n'en programme pas, ca ne m'intersse pas. Par contre, pour exemple, l'appli 'Web' de ma banque (Dexia pour ne pas la citer, c'est francais ca non?) est faite avec des applets, alors applets 'à 4 sous', je crois que ces applets ca peut servir à des choses concretes autres qu'à afficher 'Bonjour je m'appele ++Gib' sur le Web. Mais je crois qu'on peut se passer de celles ci avec des servlets ou/et des JSP qui à mon gout sont bien plus polyvalentes et plus faciles à employer sur le web...

Maintenant, la gestion des erreurs. Je sais pas ce qu'elles t'ont fait les exceptions, mais ca semble te poser un sacré problème. Peut-etre tout simplement parce qu'elle permete des chose inimaginable en C.

Attention, ceci est un forum C++/Java. Pas d'amalgame, ceci est trop courant
et trop facile. Je pourrais par exemple critiquer Java en parlant de javascript,
ce qui ne serait pas malin

C et C++ sont des langages comparables, java et javascript ne le sont pas. Si tu n'as pas compris la difference ente ces 2 langages, il vaut mieux arreter tes argumentations qui n'en sont pas ...

Dans le premier cas, si un prgm plante, un debugger moyen est capable de dire
où et pourquoi. La cause réelle initiale peut se situer très loin,
mais c'est toujours le cas en programmation. Ca peut demander
beaucoup de réflexion.

C'est vrai que dans le cas de memory leaks c'est tellement facile de trouver l'erreur de programmation, enfin je te laisse seul juge, c'est toi l'expert C++

Dans l'autre cas, il est assez osé de prétendre pouvoir analyser
par programme la cause réelle d'une exception, sutout si elle est
aussi générale que NullPointerException LORSQUE CELLE-CI PROVIENT D'UN BUG.

En java il existe le stackTrace (en c++??? je sais pas), et ta nullPointerException est on ne peut plus vite détectée...

(j'en profite au passage pour signaler que le langage-sans-pointeur vient de faire la preuve qu'il est bien difficile de s'en passer).

Ridicule! C'est pas parce qu'on ne programme pas directement avec des pointeurs qu'ils n'y en a pas gérés dans les couches inférieures... Comment faire un langage dynamique sans pointeurs??? Java est un langage dynamique, sauf que ce n'est pas la programmeur qui gère les pointeurs...

L'intérêt des exceptions est de centraliser les traitements
de situations anormales mais prévues et
d'éviter d'entrelacer le code utile avec des tests nécessaires
mais improductifs .. lorsque tout va bien. DANS CE CADRE, ça permet
de rendre le code plus clean et d'éviter un plantage, en Java comme en C++.

Oui sauf qu'en java c'est même utile quand c'est imprévu

Facile: j'observe, je mesure, je vais voir le code lorsque j'en ai l'occasion
et je considère les annonces des différents acteurs avec circonspection.
Dans l'ambiance générale commerciale, ça aide à prendre du recul.
Lorsque j'avance que j'ai mesuré des performances médiocres, je n'ai pas
besoin d'autres sources que celle de mon expérience.

Ca c'est ta version des choses et ne reste que la tienne, ne vient pas avec tes chiffres de c++ magazine... juste pour information, sur quelles(ou quelles types d') applis (et nombre d'applis) tu a fait tes conclusions???

Ca ne change rien au fait que pour compiler vers une machine cible, on doit
générer du code spécifique à celle ci (techniquement: pour cela, la partie
arrière du compilateur doit être spécifique). On retombe donc bien dans
une problématique de compilation, avec développement de la partie arrière
du compilateur pour chaque cible et les aléas liés à ce genre d'opération.
En effet, si la portabilité de la VM est garantie par le langage dans lequel
elle est rédigée (C par exemple), la génération de code objet spécifique à un
processeur est une opération nettement plus difficile à rendre portable (et le
fait que le compilateur s'exécute sous la VM n'y change rien, n'en dépaise à Clément).
Comprenez moi bien : Ce n'est pas plus ardu que de développer et de
déployer que n'importe quel compilateur, mais le le slogan "Développez une fois,
déployez partout" après ça, c'est de la promesse électorale.

Pour compiler en natif il faut du code NATIF spécifique... C'est pour tous les langaes la même chose... Sauf que pour certains langages il faudra retoucher le code SOURCE pour avoir le mêmes résultats d'une machine à l'autre. Pour ton info, il n' y a pas 36 versions de java (mise à part la tentavive de M$, mais c'est bel et bien fini et tant mieux), il n'y en a qu'une. Les compilo sont fait selon les normes de java donc ton code reste valable sur n'importe quelle machine... Il n'y a que la JVM ET le COMPILO qui sont spécifique à la machine. A partir de ce moment je voit pas trop tes problemes p/r à ca... Le seul moyen de rendre un code java inutilisable sur des machines differentes c'est de faire des CLASSES natives, autrement dit faire des interfaces sur des dll windows ou autres librairies linux tres specifiques... Et LA ton C++ intervient ...

Insister sur le fait que la JVM est spécifique au système , c'est très bien, mais il faut bien quelque chose de spécifique NON? tant qu'à ce faire, que ca ne soit pas au programmeur à s'en soucier....

Je voudrais également insister sur les appli écrites en java et les projets qu'il y a moyen d'entaler de ce langage... Pourquoi ORACLE(qui n'est pas une succurcale de SUN), 2ème producteur de soft au monde, s'oriente tellement vers java? Ce ne sont qd même pas les conclusions d'un ++gib, anonyme, qui n'aime pas java par pure conviction ...

Enormément de programmeurs paniquent à la vue des pointeurs et avec l'allocation dynamique. J'ai d'ailleurs observé que c'est ceux-là qui ont filé
vers Java au début...encouragés par la pub de Sun. Sont-ils devenus
bons pour autant ?

Ceux qui n'ont pas paniqué sont ils eux des des grand manie-tout des pointeurs???

Pour finalize() Je crois que ce n'est pas tres souvent utilisé mais c'est bien que cela exite au cas où... alors rustine??? je crois pas.

Un point ou je suis partiellement d'accord ce sont les destructeurs. D'un côté ca ca manque en java, mais c'est en contradiction, je trouves, avec le GC.

Pourquoi finally est une rustine ? Parcequ'elle a pour but de
rattrapper le defaut précédent. Lorsqu'une exception est lancée en C++
les objets locaux à la méthode sortent de leur portée, ils sont donc déalloués
et leur destructeur est exécuté. Ce destructeur est donc un endroit naturel
pour liberer des ressources locales à la fonction, quel qu'elles soient.
C'est la mise en oeuvre du principe "la construction est une allocation
de ressource" (donc la destruction est une restitution).

En c++ il faut un destucteur, en java il faut soit une méthode finalize, soit finally dans un bloc, en quoi ca pose probleme??? Par ton propre raisonnement il faut croire que le destucteur en c++ est une rustine...

Sun a replacé quelque chose de clean par autre chose d'inutilement compliqué
et de moins efficace

Ouvrir un fichier / Fermer un fichier Oulala c'est difficile, c'est compliqué. fianlize ? finally? pffff difficile... Il ne faudrait pas exagérer non plus... ca fait parti de la philo du langage, point final! dire que c'est compliqué c'est n'importe quoi...

Effectivement, ce coup de pub n'est pas un hasard. Java a très vite trouvé le
public de ceux pour qui la facilité de développement compte plus
que le résultat.

Le coup de pub, comme tu dis, ben il porté ses fruits dans beaucoup de projets. Sinon je crois que java aurait été abandonné depuis belle lurette....

Pour le reste, on pourrait en dire autant de tous les langages

Sauf le c++ quand même, on ne voudrait tout de même pas 'entâcher' ce langage 'noble' et sans aucun reproche...

[Solaris]

Il me semble que l'on oubli l'avantage de loin le plus important de Java:
c'est un langage managé.

celà signifie en particulier que ton appli va s'exécuter dans un environnement contrôlé.

L'environnement va contrôler l'usage que tu fais de la mémoire (tu sais les pbl de fuite de mémoire qui sont la signature des applis écrites en C)

l'environnement va contrôler l'accès que tu fais des resources: par exemple les pbl de débordement de tampon doivent facilement représenter 50% des bogues de sécurité

l'environnement peut prendre en charge la sécurité de ton code

bien sûr les programmeurs C vont te dire qu'ils peuvent faire celà. Le pbl est que:
1) ils ne le font jamais
2) java offre une méthode standardisé pour le faire

Je suis convaincu que l'avenir est aux langages managés. C et C++ vont perdre pas mal de leur superbe dans les prochaines années lorsque les DI calculeront les économies en productivité que réalise une appli écrite en langage managé.

Cela ne signifie pas que l'on ne fera plus du C évidemment. A un certain niveau un environnement managé est bien obligé de s'appuyer sur du code non managé.
De plus l'environnement a forcément un coût de structure sur les performances et la consommation des resources et certaines applis ne peuvent pas se le permettre (calculs numériques, drivers, embarqué dans certains cas...)

Mon avis est donc plutôt de te former à Java, mais aussi à .NET et surtout de ne pas perdre de vue ta première expérience en PHP qui pour le web est une alternative plus économique et plus simple que les deux poids lourds.

C/C++ pourquoi pas certes, il serai irresponsable de prétendre que celà te mènera nulle part. Mais il faut être réaliste. Les langages managés comme Java sont sur une pente ascendante, on ne peut pas en dire autant de C/C++... La certification ISO de C++ ne changera rien à l'affaire.



j'enfonce encore le clou:
le principal avantage de C++ évoqué ici est la rapidité.

Je reste convaincu que des critères comme la fiabilité du code, la sécurité, la maintenabilité et l'évolutivité sont des critères autrement plus utiles dans la plupart des applis que nous écrivons tous et C/C++ n'est pas particulièrement bon la dedans. Justement parce que avec ces langages tu dois tout faire toi même. Ne rêvons pas.
On peut arriver à optimiser quelques centaines de lignes, pas des dizaines de milliers à nous tout seul.

D'autre part on dit souvent (avec parfois raison) que Java est lent. Oui, mais faut pas non plus exagérer.
C'est sûr que lorsque le CEA évalue l'informatique nécessaire pour simuler sur ordinateur l'explosion d'une bombe nucléaire il ne viendra à l'idée de personne de se servir de Java pour les calculs. Franchement est-ce le type d'appli que l'on écrit couramment?

Donc: Java/.NET et une goutte de C si tu as du temps devant toi...

Oula, je vais me faire des ennemis ici

[beremeth]

Salut à tous,

Je veux pas rentrer dans la polèmique C++ vs Java, mais c'était pour répondre au sujet initial.

Je pense qu'apprendre correctement les bases du C est important pour pouvoir après migrer vers d'autres langages plus évolués.

1/ le C est simple et clair, il permet (oblige) d'être rigoureux lors de la conception de programme.

2/ sa synthaxe a été reprise dans les grandes lignes par bon nombre de langages. Ces langages repoussent les limites maximales mais gardent pour lot commun un héritage de base C très fort(exemple simple les "chaines de caractères" et les fins de ligne;, les tableaux[] aussi).

Donc, pour Gregork, fais un rapide survol du C avant de te lancer dans le C++, C# ou Java (sauf si je me trompe, .Net n'est qu'une API (mais comme je developpe pas sous win, je me tiens pas assez informé de son évolution)). Ca t'aidera et te fera gagner ulterieurement du temps pendant le "codage" et l'optimisation de tes futurs programmes.

Bref, pour moi, on n'apprend pas a multiplier avant de savoir additionner