Je suis prêt à accorder qu'il reste un avantage à C++ pour la
rapidité, de plus en plus marginal d'ailleurs.
Il est vrai aussi que cette avantage se paie par des temps de
développement colossaux.
Alors quelles sont les raisons de la persistence de C++ dans des
projets anciens et nouveaux ?
Je pense que la vraie raison de la persistence de C++ tient à 2
facteurs:
- 1. il y a du code hérité ("legacy"), C et C++
- 2. les mauvaises performances de nombreuses applications Java
Sur le point 2, il me semble que le problème n'est pas dû de manière
intrinsèque à Java, mais peut-être à la JVM ou à la bibliothèque
standard.
Mais surtout il me semble que le facteur "culturel" est très
important.
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Et cela pour une raison bien simple: écrire une application Java
utilisable mais peu performante est possible sans cette conscience
claire .
Alors qu'en C/C++ c'est presque impossible.
L'exemple typique d'application où Java n'a pas percé est le
navigateur.
Je suis prêt à accorder qu'il reste un avantage à C++ pour la
rapidité, de plus en plus marginal d'ailleurs.
Il est vrai aussi que cette avantage se paie par des temps de
développement colossaux.
Alors quelles sont les raisons de la persistence de C++ dans des
projets anciens et nouveaux ?
Je pense que la vraie raison de la persistence de C++ tient à 2
facteurs:
- 1. il y a du code hérité ("legacy"), C et C++
- 2. les mauvaises performances de nombreuses applications Java
Sur le point 2, il me semble que le problème n'est pas dû de manière
intrinsèque à Java, mais peut-être à la JVM ou à la bibliothèque
standard.
Mais surtout il me semble que le facteur "culturel" est très
important.
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Et cela pour une raison bien simple: écrire une application Java
utilisable mais peu performante est possible sans cette conscience
claire .
Alors qu'en C/C++ c'est presque impossible.
L'exemple typique d'application où Java n'a pas percé est le
navigateur.
Je suis prêt à accorder qu'il reste un avantage à C++ pour la
rapidité, de plus en plus marginal d'ailleurs.
Il est vrai aussi que cette avantage se paie par des temps de
développement colossaux.
Alors quelles sont les raisons de la persistence de C++ dans des
projets anciens et nouveaux ?
Je pense que la vraie raison de la persistence de C++ tient à 2
facteurs:
- 1. il y a du code hérité ("legacy"), C et C++
- 2. les mauvaises performances de nombreuses applications Java
Sur le point 2, il me semble que le problème n'est pas dû de manière
intrinsèque à Java, mais peut-être à la JVM ou à la bibliothèque
standard.
Mais surtout il me semble que le facteur "culturel" est très
important.
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Et cela pour une raison bien simple: écrire une application Java
utilisable mais peu performante est possible sans cette conscience
claire .
Alors qu'en C/C++ c'est presque impossible.
L'exemple typique d'application où Java n'a pas percé est le
navigateur.
>> Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.
>> Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.
>> Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.
Et jusqu'à certains qui croient que le GC est capable de décider ce qui
doit être garbager sans besoin de dé-référencer!
Sur la derniere remarque, chaque JVM ( Sun, IBM,Oracle/BEA, ...) a une
multitutide de parametres qui permettent de gérer la stratégie
d'allocation et garbage. C'est là souvent que ce joue une partie de la
performance de l'application ( l'autre partie étant la (mauvaise)
qualité du code).
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.
Et jusqu'à certains qui croient que le GC est capable de décider ce qui
doit être garbager sans besoin de dé-référencer!
Sur la derniere remarque, chaque JVM ( Sun, IBM,Oracle/BEA, ...) a une
multitutide de parametres qui permettent de gérer la stratégie
d'allocation et garbage. C'est là souvent que ce joue une partie de la
performance de l'application ( l'autre partie étant la (mauvaise)
qualité du code).
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.
Et jusqu'à certains qui croient que le GC est capable de décider ce qui
doit être garbager sans besoin de dé-référencer!
Sur la derniere remarque, chaque JVM ( Sun, IBM,Oracle/BEA, ...) a une
multitutide de parametres qui permettent de gérer la stratégie
d'allocation et garbage. C'est là souvent que ce joue une partie de la
performance de l'application ( l'autre partie étant la (mauvaise)
qualité du code).
Bonjour,
a écrit :Je suis prêt à accorder qu'il reste un avantage à C++ pour la
rapidité, de plus en plus marginal d'ailleurs.
Marginal, c'est discutable. La même chose se fait peut-être en à peu
près le même temps dans les deux langages. Mais C++ permet d'envisager
des méthodes que Java ne permet pas (sans JNI). Et qui peuvent être plus
rapides.
Je suppose que cela arrive souvent en pratique.Il est vrai aussi que cette avantage se paie par des temps de
développement colossaux.Alors quelles sont les raisons de la persistence de C++ dans des
projets anciens et nouveaux ?
Je pense que la vraie raison de la persistence de C++ tient à 2
facteurs:
- 1. il y a du code hérité ("legacy"), C et C++
C'est tout de même un point qui me semble important !- 2. les mauvaises performances de nombreuses applications JavaSur le point 2, il me semble que le problème n'est pas dû de manière
intrinsèque à Java, mais peut-être à la JVM ou à la bibliothèque
standard.
Mais surtout il me semble que le facteur "culturel" est très
important.
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.
Bonjour,
jeanmarc.vanel@gmail.com a écrit :
Je suis prêt à accorder qu'il reste un avantage à C++ pour la
rapidité, de plus en plus marginal d'ailleurs.
Marginal, c'est discutable. La même chose se fait peut-être en à peu
près le même temps dans les deux langages. Mais C++ permet d'envisager
des méthodes que Java ne permet pas (sans JNI). Et qui peuvent être plus
rapides.
Je suppose que cela arrive souvent en pratique.
Il est vrai aussi que cette avantage se paie par des temps de
développement colossaux.
Alors quelles sont les raisons de la persistence de C++ dans des
projets anciens et nouveaux ?
Je pense que la vraie raison de la persistence de C++ tient à 2
facteurs:
- 1. il y a du code hérité ("legacy"), C et C++
C'est tout de même un point qui me semble important !
- 2. les mauvaises performances de nombreuses applications Java
Sur le point 2, il me semble que le problème n'est pas dû de manière
intrinsèque à Java, mais peut-être à la JVM ou à la bibliothèque
standard.
Mais surtout il me semble que le facteur "culturel" est très
important.
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.
Bonjour,
a écrit :Je suis prêt à accorder qu'il reste un avantage à C++ pour la
rapidité, de plus en plus marginal d'ailleurs.
Marginal, c'est discutable. La même chose se fait peut-être en à peu
près le même temps dans les deux langages. Mais C++ permet d'envisager
des méthodes que Java ne permet pas (sans JNI). Et qui peuvent être plus
rapides.
Je suppose que cela arrive souvent en pratique.Il est vrai aussi que cette avantage se paie par des temps de
développement colossaux.Alors quelles sont les raisons de la persistence de C++ dans des
projets anciens et nouveaux ?
Je pense que la vraie raison de la persistence de C++ tient à 2
facteurs:
- 1. il y a du code hérité ("legacy"), C et C++
C'est tout de même un point qui me semble important !- 2. les mauvaises performances de nombreuses applications JavaSur le point 2, il me semble que le problème n'est pas dû de manière
intrinsèque à Java, mais peut-être à la JVM ou à la bibliothèque
standard.
Mais surtout il me semble que le facteur "culturel" est très
important.
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.
jlp wrote:Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
jlp wrote:
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.
Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
jlp wrote:Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Jean-Claude Arbaut a écrit :jlp wrote:Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où le
développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).
Jean-Claude Arbaut a écrit :
jlp wrote:
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.
Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où le
développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).
Jean-Claude Arbaut a écrit :jlp wrote:Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où le
développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où le
développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).
Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où le
développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).
Et jusqu'à certains qui croient que le GC est capable de décider ce
qui doit être garbager sans besoin de dé-référencer!
Tiens, je prends le fil au passage :-) Si on a une structure de
données assez complexe (nombreux pointeurs, éventuellement
avec des "cycles"), est-il suffisant de "déréférencer" la ou les
variables qui accèdent à tout ça, ou faut-il "casser" la structure ?
(est-ce que ça change quelque chose pour le GC ?)
Ben non justement, il faut dé-référencer toutes les ressources.
Par exemple la fuite mémoire de débutant sont sur les Collections où le
développeur dé-référence la Collection ( le conteneur) sans
dé-référencer le contenu ( sans faire Collection.clear() par exemple).
Salut.
Es-tu sur?
C'est l'opposé de la réponse de Samuel Devulder
(<4929ac3a$0$27457$)
Pour faire plus simple je la cite :
==== > ...
==== >
Si tu déréférences un Vecteur par exemple (en supposant que ses
éléments ne soient pas référencés ailleurs), on se retrouve face à
la "structure complexe sur un ilôt isolé" non?
Sinon on va finir par regretter les destructeurs du C++ qui eux sont
appelés à coup sur, contrairement au finalize ;)
Eric.
Salut.
Es-tu sur?
C'est l'opposé de la réponse de Samuel Devulder
(<4929ac3a$0$27457$426a34cc@news.free.fr>)
Pour faire plus simple je la cite :
==== > ...
==== >
Si tu déréférences un Vecteur par exemple (en supposant que ses
éléments ne soient pas référencés ailleurs), on se retrouve face à
la "structure complexe sur un ilôt isolé" non?
Sinon on va finir par regretter les destructeurs du C++ qui eux sont
appelés à coup sur, contrairement au finalize ;)
Eric.
Salut.
Es-tu sur?
C'est l'opposé de la réponse de Samuel Devulder
(<4929ac3a$0$27457$)
Pour faire plus simple je la cite :
==== > ...
==== >
Si tu déréférences un Vecteur par exemple (en supposant que ses
éléments ne soient pas référencés ailleurs), on se retrouve face à
la "structure complexe sur un ilôt isolé" non?
Sinon on va finir par regretter les destructeurs du C++ qui eux sont
appelés à coup sur, contrairement au finalize ;)
Eric.
Mayeul wrote:Bonjour,
a écrit :Je suis prêt à accorder qu'il reste un avantage à C++ pour la
rapidité, de plus en plus marginal d'ailleurs.
Marginal, c'est discutable. La même chose se fait peut-être en à peu
près le même temps dans les deux langages. Mais C++ permet d'envisager
des méthodes que Java ne permet pas (sans JNI). Et qui peuvent être
plus rapides.
Je suppose que cela arrive souvent en pratique.Il est vrai aussi que cette avantage se paie par des temps de
développement colossaux.Alors quelles sont les raisons de la persistence de C++ dans des
projets anciens et nouveaux ?
Je pense que la vraie raison de la persistence de C++ tient à 2
facteurs:
- 1. il y a du code hérité ("legacy"), C et C++
C'est tout de même un point qui me semble important !- 2. les mauvaises performances de nombreuses applications JavaSur le point 2, il me semble que le problème n'est pas dû de manière
intrinsèque à Java, mais peut-être à la JVM ou à la bibliothèque
standard.
Mais surtout il me semble que le facteur "culturel" est très
important.
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.
Les deux ou trois premières réponses de
http://www.google.com/search?hl=en&q=site%3Ajava.sun.com+filetype%3Apdf+garbage+collector
donnent des indications intéressantes à ce sujet ;-)
"Garbage collection (GC) is probably the most widely misunderstood
feature of the Java platform. GC is typically advertised as removing all
memory management responsibility from the application developer. This
just isn’t the case."
Mayeul wrote:
Bonjour,
jeanmarc.vanel@gmail.com a écrit :
Je suis prêt à accorder qu'il reste un avantage à C++ pour la
rapidité, de plus en plus marginal d'ailleurs.
Marginal, c'est discutable. La même chose se fait peut-être en à peu
près le même temps dans les deux langages. Mais C++ permet d'envisager
des méthodes que Java ne permet pas (sans JNI). Et qui peuvent être
plus rapides.
Je suppose que cela arrive souvent en pratique.
Il est vrai aussi que cette avantage se paie par des temps de
développement colossaux.
Alors quelles sont les raisons de la persistence de C++ dans des
projets anciens et nouveaux ?
Je pense que la vraie raison de la persistence de C++ tient à 2
facteurs:
- 1. il y a du code hérité ("legacy"), C et C++
C'est tout de même un point qui me semble important !
- 2. les mauvaises performances de nombreuses applications Java
Sur le point 2, il me semble que le problème n'est pas dû de manière
intrinsèque à Java, mais peut-être à la JVM ou à la bibliothèque
standard.
Mais surtout il me semble que le facteur "culturel" est très
important.
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.
Les deux ou trois premières réponses de
http://www.google.com/search?hl=en&q=site%3Ajava.sun.com+filetype%3Apdf+garbage+collector
donnent des indications intéressantes à ce sujet ;-)
"Garbage collection (GC) is probably the most widely misunderstood
feature of the Java platform. GC is typically advertised as removing all
memory management responsibility from the application developer. This
just isn’t the case."
Mayeul wrote:Bonjour,
a écrit :Je suis prêt à accorder qu'il reste un avantage à C++ pour la
rapidité, de plus en plus marginal d'ailleurs.
Marginal, c'est discutable. La même chose se fait peut-être en à peu
près le même temps dans les deux langages. Mais C++ permet d'envisager
des méthodes que Java ne permet pas (sans JNI). Et qui peuvent être
plus rapides.
Je suppose que cela arrive souvent en pratique.Il est vrai aussi que cette avantage se paie par des temps de
développement colossaux.Alors quelles sont les raisons de la persistence de C++ dans des
projets anciens et nouveaux ?
Je pense que la vraie raison de la persistence de C++ tient à 2
facteurs:
- 1. il y a du code hérité ("legacy"), C et C++
C'est tout de même un point qui me semble important !- 2. les mauvaises performances de nombreuses applications JavaSur le point 2, il me semble que le problème n'est pas dû de manière
intrinsèque à Java, mais peut-être à la JVM ou à la bibliothèque
standard.
Mais surtout il me semble que le facteur "culturel" est très
important.
Beaucoup de développeurs Java n'ont pas une conscience claire de où et
comment la mémoire s'alloue et se désalloue, de où est passé le temps
CPU.
Par nature du garbage collector, je pense qu'il n'est pas possible
d'avoir une conscience claire de où et comment la mémoire se libère.
L'idée étant plutôt que ça ne doit pas être important.
Les deux ou trois premières réponses de
http://www.google.com/search?hl=en&q=site%3Ajava.sun.com+filetype%3Apdf+garbage+collector
donnent des indications intéressantes à ce sujet ;-)
"Garbage collection (GC) is probably the most widely misunderstood
feature of the Java platform. GC is typically advertised as removing all
memory management responsibility from the application developer. This
just isn’t the case."