[Débat] C++ vs Java

**arno31** · 10/04/2009, 11h29

En ce qui concerne les performances, cela dépendra de ton application : si ton appli fait de gros calculs mathématiques, le C++ sera surement plus performant mais dans le cas contraire il ne devrait pas y avoir de différences significatives entre les 2 langages.

En ce qui concerne la liberté, Java enlève surtout la liberté de faire n'importe quoi. Par exemple en C++, tu dois libéré toi même les ressources que tu alloues et si tu ne le fais pas personne le fera pour toi et ça peut être problématique

; en Java tu as un garbage collector qui libère les ressources qui ne sont plus utilisées. Bien sûr cela coûte un peu de ressources systèmes mais ton application risquera moins de planter.

**kpouer** · 10/04/2009, 11h40

Envoyé par arno31

En ce qui concerne la liberté, Java enlève surtout la liberté de faire n'importe quoi. Par exemple en C++, tu dois libéré toi même les ressources que tu alloues et si tu ne le fais pas personne le fera pour toi et ça peut être problématique

; en Java tu as un garbage collector qui libère les ressources qui ne sont plus utilisées. Bien sûr cela coûte un peu de ressources systèmes mais ton application risquera moins de planter.

Compter sur le garbage collector de cette manière c'est l'assurance de faire une appli raté
Ce n'est pas parce qu'il y a un garbage collector que tu ne dois pas réfléchir pour savoir a quel moment ton objet sera collectable et a quel moment il ne le sera pas

**Gabrielly** · 10/04/2009, 11h54

Compter sur le garbage collector de cette manière c'est l'assurance de faire une appli raté
Ce n'est pas parce qu'il y a un garbage collector que tu ne dois pas réfléchir pour savoir a quel moment ton objet sera collectable et a quel moment il ne le sera pas

+1
Tout à fait d'accord avec toi. Ce qui indique que C++ est plus déterministe que Java. Ceux qui savent exactement lorque les ressources sont libérées sont à mon avis de bons programmeurs.
Et de toute façon il y a aussi un garbage collector pour ce qui font du C++/CLI.

**hegros** · 10/04/2009, 13h12

on s'en moque des ressources. Il y a 5% des programmeurs en C++ qui savent ce qu'ils font avec la mémoire, les autres feraient mieux de passer à Java pour cette partie...

**rakakabe** · 10/04/2009, 13h20

Envoyé par Gabrielly

+1
Ceux qui savent exactement lorque les ressources sont libérées sont à mon avis de bons programmeurs.

Mais comment le savoir ? appeler le GC.Collect() (J'avoue que j'ai pas creuse sur l'archi des machines virtuelles) ? Je bosse maintenant en C#, mais j'ai du mal a comprendre quand est-ce que ce fameux GC va faire le menage (je fais aussi du Java quelques fois pour le plaisir mais meme probleme). J'aurais preferer les pointeurs 'intelligents' du C++ (drole d'appelation) car des que mon truc n'est plus utilise, je suis sur que ca va disparaitre TOUT DE SUITE.

**Furikawari** · 10/04/2009, 14h07

Sauf que dans 99,99% des cas ton application n'est pas critique niveau gestion mémoire et tu en as rien à foutre que la mémoire soit libérée "TOUT DE SUITE".

**_dod_** · 10/04/2009, 14h13

Il y a également le même mécanisme en C# (Garbage Collector) mais de toute façon en Java ou C# où il faut quand même faire attention aux objets qu'on manipule afin d'éviter d'encombrer inutilement la mémoire. Le Garbage Collector facilite le travail des développeurs mais c'est pas pour autant qu'ils ne doivent pas se préoccuper de la mémoire.http://msdn.microsoft.com/fr-fr/library/f144e03t.aspx

Cependant, il est important de noter que Java par exemple, introduit des concepts intéressants comme le pool mémoire réservé à certaines classes enveloppes.

**zaventem** · 10/04/2009, 14h35

Envoyé par hegros

on s'en moque des ressources. Il y a 5% des programmeurs en C++ qui savent ce qu'ils font avec la mémoire, les autres feraient mieux de passer à Java pour cette partie...

Si je puis me permettre, la mémoire ne constitue qu'une ressource parmis tant d'autres... Te moques-tu également de savoir quand une connexion à une DB sera libérée, quand un verrou sur un fichier sera relaché?

Pour ces aspects, un garbage collector est certes un outils qui évite en général les catastrophes mais qui ne fonctionne pas toujours et rarement de manière idéale.

**Furikawari** · 10/04/2009, 14h45

Envoyé par zaventem

Si je puis me permettre, la mémoire ne constitue qu'une ressource parmis tant d'autres... Te moques-tu également de savoir quand une connexion à une DB sera libérée, quand un verrou sur un fichier sera relaché?

Pour ces aspects, un garbage collector est certes un outils qui évite en général les catastrophes mais qui ne fonctionne pas toujours et rarement de manière idéale.

Ca fonctionne aussi bien qu'en C++, juste dans ce cas là c'est moins élégant. Mais pas de différence.

**hegros** · 10/04/2009, 14h46

Envoyé par zaventem

Si je puis me permettre, la mémoire ne constitue qu'une ressource parmis tant d'autres... Te moques-tu également de savoir quand une connexion à une DB sera libérée, quand un verrou sur un fichier sera relaché?

oui je m'en moque totalement.

connexion.close;connexion=null; et verrou.close;verrou=null;

me suffit parce que ma connexion est fermée et mon verrou aussi. Que les objets soient en mémoire encore je m'en moque je ne les utilise pas.

**rakakabe** · 10/04/2009, 14h47

Envoyé par Furikawari

Sauf que dans 99,99% des cas ton application n'est pas critique niveau gestion mémoire et tu en as rien à foutre que la mémoire soit libérée "TOUT DE SUITE".

Et bien, moi, je suis dans 0,01 % des cas :

essaie un peu de coder dans ton programme une methode traitant par exemple des tas des donnees pleines d'exception, le resultat ?
1 - des le premier erreur venu, ton programme disparait de l'ecran, et l'utilisateur de ton soft

va te donner des tas de

,

.
2 - si tu traites les exceptions par donnee avec un try catch et que ton garbage collector ne fait pas son boulot, la memoire occupee par ton programme va augmenter de plus de 300 % et ca va planter le matos un peu partout (compte tenu du cout du try catch), et tu va

et

, plus la consequence de la precedente.

**Luc Hermitte** · 10/04/2009, 14h48

Hegros, Tu viens d'écrire que tu ne te moques pas de savoir quand la ressource est relachée -- ils ne parlaient pas de la zone mémoire associée à la gestion de la ressource, mais bien de la ressource.

**Furikawari** · 10/04/2009, 14h51

Envoyé par rakakabe

Et bien, moi, je suis dans 0,01 % des cas :

essaie un peu de coder dans ton programme une methode traitant par exemple des tas des donnees pleines d'exception, le resultat ?
1 - des le premier erreur venu, ton programme disparait de l'ecran, et l'utilisateur de ton soft

va te donner des tas de

,

.
2 - si tu traites les exceptions par donnee avec un try catch et que ton garbage collector ne fait pas son boulot, la memoire occupee par ton programme va augmenter de plus de 300 % et ca va planter le matos un peu partout (compte tenu du cout du try catch), et tu va

et

, plus la consequence de la precedente.

(ton post est illisible avec la multiplication des fautes et des smileys...).

Faut revoir un peu le principe du GC : il ne libère pas tout de suite la mémoire SI elle n'est pas réutilisée de suite. Sinon il la réutilise directement (puisque tu l'a réveillé en faisant une nouvelle allocation). Pour ton histoire d'exception j'ai pas tout compris, mais en java tu as finally à utiliser.

**Furikawari** · 10/04/2009, 14h52

Envoyé par Luc Hermitte

Hegros, Tu viens d'écrire que tu ne te moques pas de savoir quand la ressource est relachée -- ils ne parlaient pas de la zone mémoire associée à la gestion de la ressource, mais bien de la ressource.

Avec un finally bien scopé ta ressource sera libérée de suite. Comme je disais c'est juste plus lourd qu'en C++, c'est tout (au niveau de la syntaxe).

**adiGuba** · 10/04/2009, 15h07

Envoyé par rakakabe

Mais comment le savoir ? appeler le GC.Collect() (J'avoue que j'ai pas creuse sur l'archi des machines virtuelles) ?

Non surtout pas !
En règle général cela aboutit à un appel inutile consommateur en temps CPU...

Envoyé par rakakabe

Je bosse maintenant en C#, mais j'ai du mal a comprendre quand est-ce que ce fameux GC va faire le menage (je fais aussi du Java quelques fois pour le plaisir mais meme probleme).

Tu n'as pas à te soucier de savoir quand exactement. Tu sais juste que la référence est "libérable" lorsqu'elle n'est plus accessible.

Pour la mémoire c'est amplement suffisant. Le GC ne la libèrera pas forcément de suite mais ce n'est pas gênant car il alloue la mémoire par bloc : ce n'est pas cela qui va provoquer une grosse consommation mémoire !

Bref une bonne gestion de la mémoire consiste a bien choisir le scope des variables, c'est à dire a le limiter leurs portées à ce qui est réellement utile (par ex: ne pas utiliser d'attributs d'instance ou static comme variable locale, etc.)

Envoyé par rakakabe

J'aurais preferer les pointeurs 'intelligents' du C++ (drole d'appelation) car des que mon truc n'est plus utilise, je suis sur que ca va disparaitre TOUT DE SUITE.

Ce serait utile... pour les ressources externes où il y a de gros besoin !

Mais cela n'est d'aucune utilité pour la mémoire en elle-même à moins de ne vouloir minimisé au maximum l'utilisation de la mémoire.
De par le fonctionnement du GC, il n'y a aucun intérêt à connaitre avec précision le moment où l'objet sera supprimé de la mémoire...

Envoyé par zaventem

Si je puis me permettre, la mémoire ne constitue qu'une ressource parmis tant d'autres... Te moques-tu également de savoir quand une connexion à une DB sera libérée, quand un verrou sur un fichier sera relaché?

Justement non : la mémoire n'est pas une ressource comme les autres puisqu'elle est géré par le GC...

Attention car dans vos messages en général vous mélangez mémoire et ressources (fichiers, sockets, etc.).
Le GC ne s'occupe QUE de la mémoire, et dans ce cas là il y a peu d'intérêt à libérer les objets tout de suite. Au contraire le fait que le GC les alloue par bloc apporte de meilleurs performances...

A l'inverse pour les ressources le moment de libération exact est primordiale. On utilise pour cela un try/finally en Java ou le mot-clef using en C#...

a++

**zaventem** · 10/04/2009, 15h35

Envoyé par hegros

oui je m'en moque totalement.

connexion.close;connexion=null; et verrou.close;verrou=null;

me suffit parce que ma connexion est fermée et mon verrou aussi. Que les objets soient en mémoire encore je m'en moque je ne les utilise pas.

Je ne comprends pas ton argument. Comment peux-tu affirmer que tu t'en moques alors que tu spécifies explicitement de les libérer?

Envoyé par adiGuba

Justement non : la mémoire n'est pas une ressource comme les autres puisqu'elle est géré par le GC...

Je persiste à dire que la mémoire n'est qu'une ressource parmis les autres, ton objection n'illustre, à mon sens, que le fait qu'un GC ne s'occupe pas de gérer les ressources mais la mémoire.
Par analogie (et avec toutes les approximations que cela entraîne), ce n'est pas parce que mon garagiste ne répare que les voitures qu'une moto n'est pas un véhicule.

Envoyé par adiGuba

Attention car dans vos messages en général vous mélangez mémoire et ressources (fichiers, sockets, etc.).

Je ne comprends pas pourquoi tu tiens à faire cette distinction? Qu'est-ce qui te dérange dans le fait de considérer la mémoire en tant que ressources? Elle ne se gère pas de la même manière qu'un fichier, certes, mais lui même ne se gère pas de la même manière qu'une connexion DB, etc.

**rakakabe** · 10/04/2009, 15h40

Envoyé par Furikawari

(ton post est illisible avec la multiplication des fautes et des smileys...)..

Desole car j'utilise un clavier QWERTY.

Envoyé par Furikawari

Pour ton histoire d'exception j'ai pas tout compris, mais en java tu as finally à utiliser.

Eh bien, j'ai une methode TraiterDonnees() traitant un flot de donnees, et chaque donnee peut avoir des comportements etranges (= exception).

Si je fais comme ceci (code ecrit en C#):

Code :

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

1
2
3
4
5
6
7
8
9
10
try{
 TraiterDonnees();
}
catch(Exception e){
 // suppression des ressources
}
finally{
 // je fais GC.Collect();
}

Le probleme c'est que la premiere donnee generant une exception pourra stopper le traitement des donnees restantes (et c'est la frustration garantie pour les utilisateurs).

Alors, j'ai fait un truc du genre :

Code :

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

1
2
3
4
5
6
7
8
9
10
Data [] donnee; // la collection de donnees a traiter 
for(int i = 0; i < nombreDonnees; i++){
 try{
  TraiterDonnee(donnee[i]); 
}
catch(Exception e){
// suppression des ressources
}
}

Ainsi, s'il y a plus de donnees erronees, alors la suppression des ressources devient problematique avec le GC, et cela plante le matos.

**zaventem** · 10/04/2009, 15h54

Envoyé par rakakabe

Eh bien, j'ai une methode TraiterDonnees() traitant un flot de donnees, et chaque donnee peut avoir des comportements etranges (= exception).

Le probleme c'est que la premiere donnee generant une exception pourra stopper le traitement des donnees restantes (et c'est la frustration garantie pour les utilisateurs).

Ainsi, s'il y a plus de donnees erronees, alors la suppression des ressources devient problematique avec le GC, et cela plante le matos.

Je ne comprends pas, dans le morceau de code que tu donnes quelles sont les ressources que tu dois libérer. Sont-ce des ressources prise dans ta procédure TraiterDonnees()? Si oui, cela illustre pour moi plus un défaut de conception qu'autre chose car la gestion des erreurs devrait se faire au niveau de ta procédure.

**rakakabe** · 10/04/2009, 16h28

Envoyé par zaventem

Sont-ce des ressources prise dans ta procédure TraiterDonnees()? Si oui, cela illustre pour moi plus un défaut de conception qu'autre chose car la gestion des erreurs devrait se faire au niveau de ta procédure.

au depart, j'ai fait un TraiterDonnees() pour tous les donnees. Puis, j'ai recode et fait un TraiterChaqueDonnee() pour une seule donnee (d'ou la boucle for pour des tas de donnees). J'alloue beaucoup de memoire dans cette derniere methode, et meme si j'y met la gestion des erreurs, j'appelle tres souvent TraiterChaqueDonnee() car il y a beaucoup de donnees a traiter (imprevisibles toujours), et lorsque le nombre d'exceptions est eleve, c'est tres penalisant au niveau de la memoire et de la performance (ex : si le programme consomme 10 Mo au depart, cela peut monter a plus de 200 Mo avec un gros plantage).

C'est peut-etre un defaut de conception de ma part (et d'analyse des donnees, mon predecesseur a meme jete l'eponge la dessus) mais, j'ai pas trouve pour le moment d'autres solutions (et que l'application a ete deployee il y a longtemps)

**kpouer** · 10/04/2009, 17h48

Envoyé par rakakabe

Mais comment le savoir ? appeler le GC.Collect() (J'avoue que j'ai pas creuse sur l'archi des machines virtuelles) ? Je bosse maintenant en C#, mais j'ai du mal a comprendre quand est-ce que ce fameux GC va faire le menage (je fais aussi du Java quelques fois pour le plaisir mais meme probleme). J'aurais preferer les pointeurs 'intelligents' du C++ (drole d'appelation) car des que mon truc n'est plus utilise, je suis sur que ca va disparaitre TOUT DE SUITE.

Salut, en fait c'est System.gc() en java pour appeler le garbage collector, mais c'est en général une mauvaise idée de le faire car ca prend évidemment des ressources, et il est de toute facon appelé automatiquement en cas de besoin de mémoire par la JVM.
Savoir qu'un objet est collectable, c'est assez simple : il l'est dès qu'il n'existe plus aucune référence vers cette instance (puisqu'il n'est plus accessible il peut être collecté).
Connaitre la mécanique interne des objets peut être très utile pour gérer sa mémoire.
Le cas classique est celui d'une String. En gros c'est un char[] encapsulé, dont le contenu est immuable.
Tu fais un substring() dessus, cela va te créer une nouvelle String utilisant le même char[] en updatant les offset de début de chaine et de longueur.
Bref si tu ne sais pas comment ca marche en java, ba si t'as une String de 1 Mo que tu fais un substring pour prendre 10 chars, ta première String sera peut être collectée mais son char[] qui sera toujours utilisé dans la nouvelle ne le sera pas et ta nouvelle String bien que faisant 10 chars occupera 1 Mo de mémoire. Bien entendu un bon programmeur en tiendra compte, le mauvais croira que le garbage collector se charge de tout.
Sinon les pointeurs intelligents j'ai jamais utilisé en c++, j'ai utilisé les std::string qui me semblent similaires a cette notion non ? ou c'est encore très différent ?

[Débat] C++ vs Java

Débats sur le développement - Le Best Of

Discussions similaires

Partager

Partager