[D�bat] C++ vs Java

... donc le garbage collector convient � tout le monde ? pas de defaut ? de cas ou il se comporte mal ?

Ma remarque �tait effectivement ironique

Le garbage collector pose probl�me quand il cr�e des pauses trop longues pour l'application. C'est surtout g�nant dans l'embarqu� (les pauses sont "al�atoires" alors qu'on a besoin d'un comportement d�terministe), et dans les tr�s grosses applis, par exemple un serveur J2E avec beaucoup beaucoup de m�moire.

Pour l'embarqu� je pense que le C++ est de toute fa�on plus adapt�, pour les serveurs il y a le GC concurrent qui fait quasiment tout le boulot sans bloquer l'application.

... et vous ne pensez pas du tout que entre deux pauses du garbage collector, votre programme peut utiliser largement trop de memoire ? jamais ? dans aucun cas ?

Envoy� par epsilon68

... et vous ne pensez pas du tout que entre deux pauses du garbage collector, votre programme peut utiliser largement trop de memoire ? jamais ? dans aucun cas ?

C'est a mon avis un choix de Java de privil�gier la vitesse d'ex�cution sur l'optimisation m�moire. Ce qui ne veut pas dire qu'on ne puisse rien faire pour am�liorer les choses. Ce que beaucoup ont tendance a faire c'est se dire que comme il y a un garbage collector on se prend pas la tete sur l'optimisation m�moire, �conomiser les instantiations d'objets et tout, selon moi c'est une erreur

A chaque nouvelle version de Java, on nous a promis les m�mes choses : plus de performances, plus de portabilit�. Le constat est que Java est vraiment trop lent.

Personnellement, depuis que j'ai d�couvert l'API Qt4 coupl�e au C++, je trouve qu'elle n'a rien � envier � Java : les applications sont _r�ellement_ portables, les performances sont excellentes, l'API est riche et s'enrichit r�guli�rement. Le pied, quoi.

En plus, il y a m�me un designer pour cr�er les interfaces ainsi qu'un plugin pour Eclipse. Rien � redire.

Envoy� par kpouer

C'est a mon avis un choix de Java de privil�gier la vitesse d'ex�cution sur l'optimisation m�moire. Ce qui ne veut pas dire qu'on ne puisse rien faire pour am�liorer les choses. Ce que beaucoup ont tendance a faire c'est se dire que comme il y a un garbage collector on se prend pas la tete sur l'optimisation m�moire, �conomiser les instantiations d'objets et tout, selon moi c'est une erreur

dans mon cas il fallait une memoire > 128 Mo (surement plus mais on n'a pas test�) et sinon apres modification, seulement 40 Mo

tu ne trouves pas qu'il faut quand meme s'en pr�occuper ?
de toute facon, je n'avais pas le choix, il tournait sur une machine productive avec des resources extremement control�es ...
et tres honnetement 40 Mo c'est encore de trop, si j'avais pu le faire en C++, ca n'aurait pas depass� 4-5 Mo.

Envoy� par FloMo

A chaque nouvelle version de Java, on nous a promis les m�mes choses : plus de performances, plus de portabilit�. Le constat est que Java est vraiment trop lent.

Personnellement, depuis que j'ai d�couvert l'API Qt4 coupl�e au C++, je trouve qu'elle n'a rien � envier � Java : les applications sont _r�ellement_ portables, les performances sont excellentes, l'API est riche et s'enrichit r�guli�rement. Le pied, quoi.

En plus, il y a m�me un designer pour cr�er les interfaces ainsi qu'un plugin pour Eclipse. Rien � redire.

Ca reste moins portable que java puisque tu dois compiler ton soft pour les diff�rents OS alors qu'un soft java fonctionnera naturellement sur tous les OS.
Ca n'a l'air de rien, mais moi j'ai pas un FreeBSD ou un Mac chez moi pour compiler dessus par exemple au moins avec Java je n'ai pas ce soucis.
De plus la vitesse c'est tr�s relatif, dans une application cliente, dans 90% des cas si elle est bien programm�e en java ou en c++ on verra aucune diff�rence car le facteur limitant c'est l'utilisateur.

Envoy� par epsilon68

dans mon cas il fallait une memoire > 128 Mo (surement plus mais on n'a pas test�) et sinon apres modification, seulement 40 Mo

tu ne trouves pas qu'il faut quand meme s'en pr�occuper ?
de toute facon, je n'avais pas le choix, il tournait sur une machine productive avec des resources extremement control�es ...
et tres honnetement 40 Mo c'est encore de trop, si j'avais pu le faire en C++, ca n'aurait pas depass� 4-5 Mo.

C'est difficile a juger sans connaitre le contexte, mais si tu prend 40 Mo en Java alors que tu penses qu'en c++ tu prendrais que 5 Mo, c'est probablement qu'il y a des choses a optimiser dans ton dev java. Pour ma part je travaille sur un serveur en java qui recoit des paquets UDP (des centaines par seconde), les d�code, effectue des traitements, en r��met, tout en �tant un serveur sur lequel des clients peuvent se connecter pour r�colter divers informations, et ca prend ptet 5 Mo.

Juste par curiosit�, n'�tant que amateur je me demande dans quelle circonstance un professionnel peut se creuser la t�te � choisir l'un des deux langages pour travailler sur un projet ?

A priori je dirais que c'est tr�s rare.

Envoy� par kpouer

Pour ma part je travaille sur un serveur en java qui recoit des paquets UDP (des centaines par seconde), les d�code, effectue des traitements, en r��met, tout en �tant un serveur sur lequel des clients peuvent se connecter pour r�colter divers informations, et ca prend ptet 5 Mo.

5Mo c'est difficile � croire, mets donc ton server en charge, et tu verras que la JVM a tendance � s'etendre dans la memoire que tu lui as allou�.

La consommation m�moire excessive en Java est une chose reconnu. Meme si on arrive � vivre avec la plupart du temps, il y a des cas ou on est reellement emb�t� c'est comme ca. Franchement ca serait decevant si vous continuiez � le nier. On ne va meme pas parler de la rapidit�, vu que la plupart disent que c'est aussi rapide que du C .

Envoy� par orelero

Juste par curiosit�, n'�tant que amateur je me demande dans quelle circonstance un professionnel peut se creuser la t�te � choisir l'un des deux langages pour travailler sur un projet ?
A priori je dirais que c'est tr�s rare.

non, ca depend de la tache, de l'importance des differents facteurs comme la memoire, la rapidit�, et surtout de l'infrastructure du client.

je pense que chaque langage a �volu�, il suffit de voir dans le monde Java " Real Time Java" pour clouer le bec de ceux qui ne jure que par C++, et invers�ment allez voir les nouvelles librairies C++ pour faire plus facilement des applications solides et portables....

donc voil� il suffit juste de bien connaitre le langage et puis c'est tout faut par chercher plus loin.

a se demander qui devrait mieux connaitre Java

Envoy� par orelero

Juste par curiosit�, n'�tant que amateur je me demande dans quelle circonstance un professionnel peut se creuser la t�te � choisir l'un des deux langages pour travailler sur un projet ?

A priori je dirais que c'est tr�s rare.

Bonjour,

Moi j'avais envie de d�velopper en dotnet !

Au boulot on ne veut pas entendre parler de la technologique de chez Microsoft et on ne jure (les d�cideurs ?) que par Java.

Assez bizarrement je me retrouve aujourd'hui a coder aussi rapidement que lorsque je faisais du VB6 et a r�aliser mes �crans avec tout autant de facilit�. Merci NetBeans et Matisse.

L'ironie est que mes applications Java ne tournent et ne tourneront que sous Windows ce qui signifie que le crit�re de la portabilit� n'est pas.

Quant aux performances je dois dire que je suis agr�ablement surpris car bien souvent les goulots dans une application sont li�s � de "mauvaises" habitudes... h�ritage du lourd pass�.

Le plus dur quant on impose une technologie autre que celle que l'on a envie d'apprendre est d'y trouver son plaisir. Une fois celui-ci trouv� le reste vient presque tout seul.

tr�s honn�tement j'aime Java mais je sais reconnaitre ses faiblesses quand elles sont visibles.

Envoy� par epsilon68

tr�s honn�tement j'aime Java mais je sais reconnaitre ses faiblesses quand elles sont visibles.

Bah tant mieux pour toi.

Envoy� par knoum

Bah tant mieux pour toi.

tu aurais mieux fait de justifier:

bien souvent les goulots dans une application sont li�s � de "mauvaises" habitudes... h�ritage du lourd pass�.

Envoy� par epsilon68

tu aurais mieux fait de justifier:

Tout d'abord il faut lire "h�ritage d'un lourd pass�" et non "h�ritage du lourd pass�".

Maintenant tu colles ce que tu veux derri�re cette phrase.

En ce qui me concerne cela signifie que j'ai eu une mauvaise approche en d�veloppant en VB6.

Cela ne veut en aucun cas dire que je critique VB ou les technologies Microsoft. J'essaie seulement d'avoir un avis critique quant � la fa�on que j'avais de d�velopper � l'�poque. Si les langages �voluent il faut bien que les d�veloppeurs �voluent aussi.

Je pense que sans Java ou la POO - � travers un autre langage - j'aurais gard� cette fa�on de coder.

Ma r�ponse initiale �tait li�e � la question de "orelero" et n'est pas en relation directe avec le sujet de cette discussion (C++ vs Java).

Sur ce bon d�veloppement.

Il est incontestable que java est bcp mieux que c++ car il es plus �quilibr�
dans Java 1.5 on a

typage
garbage collector
type g�n�rique (mieux qu'en c++)
simple heritage de classe
heritage multiple d'interface
notion d'interface
creation de thread built - in
Meta model en lecture , pas de meta class
Closure (sorte de lambda ) en utilsant les classes anonymes mais tr�s lourd syntaxiquement
pas de debuggage dans le m�me process
modification de classe a l'execution mais tr�s limit� (pour l'instant )
Appel dynamique de m�thode
Portable
interfacage DLL complexe il faut d�velopp� une couche supl�mentaire (
remarque il existe un framework payant pour interfac� une DLL sans dev suppl�mentaitre )

dans le C++ on a
typage
pas de garbage collector
type g�n�rique
heritage multiple de classe (possibilit� heritage tr�s riche mais tr�s complexe)
thread en utilisant des APIs externes (plus lourd )
pas de Meta model en lecture , pas de meta class
pas de closure (sorte de lambda )
pas de debuggage dans le m�me process
modification de classe a l'execution impossible ou tr�s tr�s tr�s limit�
pas d'appel dynamique de m�thode
Pas Portable
interface DLL sans dev suppl�mentaire

Pour n'importe quel appli Java si on a un probl�me de performance en terme de calcul on peut isoler le code et le mettre dans une JNI.

Si la taille de l'application de l'image est trop importante il y faut chercher a optimiser en utilisant des ClassLoader, et faire du profiling sur le code

De plus il y a des options pour partager les Classes entre JVM

Avant je pensait que java �tait lent et peut performant depuis que je d�veloppe avec java monkey engine je me dis que on peut - �tre un peut moin de performance mais on d�veloppe bcp plus vite.


C'est sur dans l'absolu le C++ est plus rapide et moin gourmand en espace m�moire mais la charge de d�veloppement est bcp plus importante....

Pour java il me semble que tu peux choisir entre un mode totalement interpr�t� comme c'�tait le cas dans les anciennes versions (1.2 ?) et un mode compil� (JIT) qui optimise le code � la vol�e selon l'environement (dans certains cas, para�t que les perfs sont meilleurs qu'en C++) ce qui restera strictement impossible avec le C++.