[Débat] C++ vs Java

Version imprimable

Voir 40 message(s) de cette discussion en une page

16/11/2007, 17h39
adiGuba
Citation:

Envoyé par epsilon68

tu confonds probleme d'implementation et detail d'implementation

Un détail qui utilise plus de 256 Mo quand même...

Citation:

Envoyé par epsilon68

ne confond pas non plus avec le C++, un probleme de pointeur n'est pas la meme chose. Dans mon cas le programme Java fonctionnait mais prenait trop de memoire. Desolé tu ne peux pas avoir cela en C++.

Non en C++ il n'y a aucun problème de mémoire c'est bien connu !

Citation:

Envoyé par epsilon68

au fait partant de cela, tous les problemes memoires vont finir par nous faire modifier le code puisque la configuration du GC n'y pourra jamais rien

Comme je l'ai dit le GC ne sert pas à régler les problèmes d'utilisation mémoire, mais à gérer l'allocation/libération des objets...

2 choses :
- On pourrait voir ton code (avant et après) pour mieux se faire un idée de ce qu'on parle ?
- Tu pourrais expliquer en quoi le GC ne fait pas son travail (en indiquant dans ce cas précis ce qu'il devrait faire).
Parce que là on parle un peu dans le vide...

a++
16/11/2007, 17h47
epsilon68

tu es de mauvaise foi, ca sert a rien de continuer.

je travaille dans une entreprise, je ne pourrais pas te montrer le code et tu le sais bien. En outre le probleme que je decris est un probleme hyper courant, alors je ne vois pas ce que le code pourrait mieux apporter, sinon des problemes de confidentialités pour moi.

et pour finir le GC doit régler l'utilisation memoire, et pas que avec Java on n'utilise que des pools d'objets partout parce qu'il est incapable de s'en sortir correctement. Je te signale que je parle de String de 500 Ko en moyenne

Citation:

Envoyé par epsilon68

et pour finir le GC doit régler l'utilisation memoire, et pas que avec Java on n'utilise que des pools d'objets partout parce qu'il est incapable de s'en sortir correctement. Je te signale que je parle de String de 500 Ko en moyenne

:koi:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
public class TestGC {
 
	public static void doNothing(String s) {
		int len = s.length();
		//System.out.println("Size of string is "+len/1024+" Ko");
	}
 
	public static void main(String[] args) {
 
		for(int loop=0;loop<100;loop++) {
 
			// report free memory
			long freemem = Runtime.getRuntime().freeMemory()/1024;
			long totalmem = Runtime.getRuntime().totalMemory()/1024;
			System.out.println("loop #"+loop+". Free memory: "+freemem+"/"+totalmem+" Ko");
 
			// build StringBuffer: 500Ko in average
			StringBuffer sb = new StringBuffer();
			int sizeInKo = 500+(int)(250*(Math.random()-0.5));
			for(int i=0;i<sizeInKo;i++) 
				sb.append(new char[1024]); 
 
			// convert to String and call a method 
			doNothing(sb.toString());
		}
 
	}
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
loop #0. Free memory: 4862/5056 Ko
loop #1. Free memory: 2798/5056 Ko
loop #2. Free memory: 1022/5056 Ko
loop #3. Free memory: 1839/5056 Ko
loop #4. Free memory: 1701/5056 Ko
loop #5. Free memory: 2598/5056 Ko
loop #6. Free memory: 853/5056 Ko
loop #7. Free memory: 1761/5056 Ko
loop #8. Free memory: 1799/5056 Ko
loop #9. Free memory: 1970/5056 Ko
loop #10. Free memory: 3005/5056 Ko
loop #11. Free memory: 864/5056 Ko
loop #12. Free memory: 1982/5056 Ko
loop #13. Free memory: 1701/5056 Ko
loop #14. Free memory: 1727/5056 Ko
loop #15. Free memory: 1671/5056 Ko
loop #16. Free memory: 1827/5056 Ko
loop #17. Free memory: 1966/5056 Ko
loop #18. Free memory: 2949/5056 Ko
loop #19. Free memory: 1731/5056 Ko
loop #20. Free memory: 1687/5056 Ko
loop #21. Free memory: 2576/5056 Ko
loop #22. Free memory: 1773/5056 Ko
loop #23. Free memory: 2624/5056 Ko
loop #24. Free memory: 853/5056 Ko
loop #25. Free memory: 2870/5056 Ko
loop #26. Free memory: 1600/5056 Ko
loop #27. Free memory: 1711/5056 Ko
loop #28. Free memory: 1827/5056 Ko
loop #29. Free memory: 2586/5056 Ko
loop #30. Free memory: 757/5056 Ko
loop #31. Free memory: 2852/5056 Ko
loop #32. Free memory: 1005/5056 Ko
loop #33. Free memory: 1769/5056 Ko
loop #34. Free memory: 1795/5056 Ko
loop #35. Free memory: 1890/5056 Ko
loop #36. Free memory: 1845/5056 Ko
loop #37. Free memory: 1703/5056 Ko
loop #38. Free memory: 1803/5056 Ko
loop #39. Free memory: 1649/5056 Ko
loop #40. Free memory: 1922/5056 Ko
loop #41. Free memory: 2919/5056 Ko
loop #42. Free memory: 768/5056 Ko
loop #43. Free memory: 1757/5056 Ko
loop #44. Free memory: 1739/5056 Ko
loop #45. Free memory: 1801/5056 Ko
loop #46. Free memory: 1835/5056 Ko
loop #47. Free memory: 1902/5056 Ko
loop #48. Free memory: 1691/5056 Ko
loop #49. Free memory: 2556/5056 Ko
loop #50. Free memory: 1240/5056 Ko
loop #51. Free memory: 1876/5056 Ko
loop #52. Free memory: 187/5056 Ko
loop #53. Free memory: 1721/5056 Ko
loop #54. Free memory: 2602/5056 Ko
loop #55. Free memory: 1867/5056 Ko
loop #56. Free memory: 2588/5056 Ko
loop #57. Free memory: 1329/5056 Ko
loop #58. Free memory: 1647/5056 Ko
loop #59. Free memory: 1880/5056 Ko
loop #60. Free memory: 181/5056 Ko
loop #61. Free memory: 1789/5056 Ko
loop #62. Free memory: 2564/5056 Ko
loop #63. Free memory: 797/5056 Ko
loop #64. Free memory: 2798/5056 Ko
loop #65. Free memory: 1113/5056 Ko
loop #66. Free memory: 2652/5056 Ko
loop #67. Free memory: 1721/5056 Ko
loop #68. Free memory: 1783/5056 Ko
loop #69. Free memory: 2544/5056 Ko
loop #70. Free memory: 813/5056 Ko
loop #71. Free memory: 2828/5056 Ko
loop #72. Free memory: 1109/5056 Ko
loop #73. Free memory: 1799/5056 Ko
loop #74. Free memory: 2049/5056 Ko
loop #75. Free memory: 191/5056 Ko
loop #76. Free memory: 1827/5056 Ko
loop #77. Free memory: 1980/5056 Ko
loop #78. Free memory: 1679/5056 Ko
loop #79. Free memory: 2592/5056 Ko
loop #80. Free memory: 1685/5056 Ko
loop #81. Free memory: 2536/5056 Ko
loop #82. Free memory: 1821/5056 Ko
loop #83. Free memory: 1819/5056 Ko
loop #84. Free memory: 1781/5056 Ko
loop #85. Free memory: 1813/5056 Ko
loop #86. Free memory: 1651/5056 Ko
loop #87. Free memory: 1863/5056 Ko
loop #88. Free memory: 1888/5056 Ko
loop #89. Free memory: 2943/5056 Ko
loop #90. Free memory: 2981/5056 Ko
loop #91. Free memory: 2915/5056 Ko
loop #92. Free memory: 866/5056 Ko
loop #93. Free memory: 2069/5056 Ko
loop #94. Free memory: 197/5056 Ko
loop #95. Free memory: 1745/5056 Ko
loop #96. Free memory: 1916/5056 Ko
loop #97. Free memory: 3009/5056 Ko
loop #98. Free memory: 1805/5056 Ko
loop #99. Free memory: 1727/5056 Ko

16/11/2007, 20h33
bassim

pour mettre de l'huile sur le feu, voici un lien (en anglais) mettant en évidence quelques défauts du C++ :

Defective C++
16/11/2007, 20h53
adiGuba

Citation:

Envoyé par epsilon68

tu es de mauvaise foi, ca sert a rien de continuer.

Non je veux juste comprendre ton problème.
Perso le gros problème de mémoire avec les String concerne la concaténation avec + dans une boucle (qui est un antipattern en Java), mais tu nous as affirmé que ce n'était pas le cas...

Tu dis que ce problème est hyper courant, donc je ne pense pas que ce serait difficile de poster un bout de code qui montre le problème sans "violer" les droits de ton entreprise...

Je ne sais pas ce qu'il en est des autres, mais personnellement je ne vois pas quel est ce "problème hyper courant"...

a++
16/11/2007, 20h54
Kujara

Citation:

Envoyé par bassim

pour mettre de l'huile sur le feu, voici un lien (en anglais) mettant en évidence quelques défauts du C++ :

Defective C++

Hahahhaha

Mon dieu, toi tu lit ça et tu y crois ?

La moitié de ce qu'il raconte est un inconvenient seulement s'il est présenté comme tel.C'est un point fort du c++ sous une autre lumière, que l'auteur apparemment decide de passer sous silence, tout comme il semble ignorer l'existance des librairies portables et pseudo standard annexes pour le c++( boost, qt4/ wx widgets, etc ....)

Mais bon, il a raison sur quelques points : le c++ est excessivement compliqué, et est donc reservé aux gens qui savent ce qu'ils font, et qui savent completer le language avec les outils qui vont bien.
16/11/2007, 21h09
bassim

la deuxième remarque ne me parait pas si farfelu que ça, le C++ mets en général beaucoup de temps pour compiler.
Aussi, il est dit qu'il n y a pas de reflection (désolé je connais pas très bien le C++, mais j'ai déjà programmé avec)
16/11/2007, 21h19
fantomas261

au debut du debat tout le monde soutenait le c++, maintenant c est le contraire
16/11/2007, 21h20
Kujara

Citation:

Envoyé par bassim

la deuxième remarque ne me parait pas si farfelu que ça, le C++ mets en général beaucoup de temps pour compiler.
Aussi, il est dit qu'il n y a pas de reflection (désolé je connais pas très bien le C++, mais j'ai déjà programmé avec)

Exact, pas de listage de functions en runtime, ce concept est etranger au c++ comme a beaucoup d'autres languages compilés, puisqu'on ne peux rien changer durant l'execution.

Quand aux temps de compilation, ça depends du programme.Un simple hello world se compile en moins d'une seconde, mais evidemment si tu compile 2 millions de lignes de code, ça va galerer dans n'importe quel language....

Et non, j'ai pas de benchmarks sous la main, mais est-ce vraiment necessaire ?
16/11/2007, 21h29
gorgonite

au passage, peut-on connaitre la version de la jvm que tu utilisais à l'époque de ton problème ? parce que le GC a fini par passe de l'état "minimaliste limite pathétique" à "moyennement efficace"
16/11/2007, 23h40
pseudocode

troll et contre-troll

Citation:

Envoyé par gorgonite

parce que le GC a fini par passe de l'état "minimaliste limite pathétique" à "moyennement efficace"

Faut dire aussi que la JVM est codée en C/C++, alors forcément faut pas attendre beaucoup d'efficacité... :mrgreen:

Citation:

Envoyé par bassim

pour mettre de l'huile sur le feu, voici un lien (en anglais) mettant en évidence quelques défauts du C++ :

Defective C++

Bon, allons-y...

*No compile time encapsulation
C'est tout simplement faux. A partir du moment ou 2 classes se trouvent dans des fichiers différents, si l'on change la partie privée de l'une d'entre elle, il ne faut pas recompiler nécessairement l'autre. Le saul cas ou cela pourrait arriver c'est si l'on stocke directement une variable d'un type donnée plutot que de stocker un pointeur (ou une reference), ce qui est plutot une mauvaise idée. En plus, j'ai déjà vu des techniques qui permettent d'éviter totalement cela et qui sont faciles à mettre en oeuvre.

*Outstandingly complicated grammar
C'est vrai que la syntaxe est un peu lourde, mais bon. Avec un peu d'habitude, on s'y fait sans trop de problème. Quand au temps de compilation... c'est vrai que le c++ est plutot long à compiler, mais en pratique on sent très peu la différence.

*No way to locate definitions
Ben oui, on doit mettre les fichiers en utilisant la directive #include. Mais en même temps, les fichiers inclus sont rarement super lourd, puisqu'ils ne contiennent que des déclarations. Mais c'est vrai que ce n'est pas un comportement "optimal".

*No run time encapsulation
Forcément, si tu t'amuses à utiliser des int[] et des char* en lieu et place des vector<int> et des string, normal que t'ai des problèmes. Mais si tu fais ça, alors ton niveau est vraiment tout proche de celui d'un débutant en C++. Maintenant, essaie une fois d'utiliser des vecteurs, string, map et autres smart_pointeurs et tu verras, etrangement ton code se comportera de la même façon que des langages comme java ou encore C#. (PAS POSSIBLE!)

*No binary implementation rules
C'est vrai, le fait qu'il n'y ai pas de règles au niveau binaire peut induire certains problème. Je ne pense pas ici aux debuggueurs (en fait c'est même un assez mauvais exemple je trouve), mais le problème qui consiste à utiliser une lib complée avec le compilateur A dans un programme que l'on compilr avec un compilo B est bien réel.
Maintenant, fixer une interface binaire pour le langage a d'autre inconvéniants, comme par exemple le fait que les fournisseurs de ses compilos auront beaucoup (mais vraiment beaucoup) moins de libertés en matière d'optimisations par exemple.
Je crois en fait que c'est un sujet intéressant qui mériterai d'être débattu en fait.

*No reflection
Pas totalement vrai. Il est en effet tout à fait possible de retrouver le type d'une variable donnée. Mais c'est vrai qu'il n'est pas possible d'automatiser la sérialization d'un objet. D'une manière générale, tout comportement en C++ doit être spécifié (ou si vous préférez programmé) quelque part. (sauf cas du constructeur de copie qui fait exception à la règle). C'est une choix comme un autre. Mais en même temps, une fonction de sérialisation va souvent ressembler à quelque chose du style
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 void maclasse::serialize(stream out) { //on suppose que maclasse a 3 membres e,b et c a->serialize(out); b->serialize(out); c->serialize(out); } //rmq: j'utilise un pointeur ici pour + de lisibilté. En pratique j'utiliserai plutot un shared_ptr ou qqch du style. maclasse* maclasse::deserialize(stream in) { maclasse* res = new maclasse(); res->a == type_de_a::deserialize(out); res->b == type_de_b::deserialize(out); res->c == type_de_c::deserialize(out); }
Evidement ce code est simplifié et ne fonctionnera pas comme tel, mais enfin ça donne une idée générale. Et honnêtement ce type de code va super-vite à écrire. En automatisant cela, tout ce que l'on fait c'est gagner le temps que ça mets de taper ce code, au rique de produire un code qui peut se révéler incorrect. (cas ou on n'est pas censé sérialiser un membre, et ce pour une raison x,y ou z. Cela revient me semble-t-il au cas des variable transcient et non-transcient en java, ou qqch du style (suis pas un expert en java) ).

*Very complicated type system
Il dit que le système de typage est compliqué, je suis plutot tenté de dire qu'il est complet, et très précis qui plus est. C'est plutot intéresasant dans la mesure ou ça permet de détecter pas mal d'erreurs au moment de la compilation. En plus, grâce au système de templates, on peut écrire du code super-générique. En utilisant les spécialisations, on en arrive à la métaprogrammation qui permet d'écrire du code beaucoup plus réutilisable que dans les autres langages (juste un des principes de bases de la programmation).

*Very complicated type-based binding rules
Ben en gros on autorise à avoir des fonctions qui ont le même nom mais reçoivent des paramètres différents. Pour cela, tout ce qu'il y a à savoir c'est que l'on utilise la signature de la fonction, et non uniquement son nom. Je vois pas ou est le problème. (A moins que ça l'amuse de nommer ces fonctions
Code:

1 2 3 void afuncwithTypeA(const A& a); void samefuncwithTypeB(const B& b); //..
*Defective exceptions
Encore une fois, il y a du faux dans ce que l'auteur dit. Tout d'abord, c'est vrai qu'il faux desallouer des variables quand un constructeur lance une exception. Mais (et il le dit lui-même), les shared_ptr par exemple peuvent économiser la plupart (totalité?) du travail. Ensuite, il parle d'un problème concernant le backtrace... moi je veux bien mais la fonction backtrace existe (mais s'il est vrai qu'elle ne fait pas parti du standart C++ vu que c'est une fonction C). Donc je vois pas ou vraiment est le problème.

*Duplicate facilities
C'est pourtant simple. Le C++ encapsule la plupart des types du C pour faciliter la vie du programmeur. Mais s'il veut se la compliquer, libre à lui.

*No high-level built-in types
Dans cette partie, l'auteur se contente de reprendre des trucs qu'il a déjà dit plus haut. Quand à son quiz ... j'ai mis environ 10 secondes pour trouver le problème.

*Manual memory management
Avantage ou inconvéniant? A chacun de juger. Mais le C++ encapsule déjà pas mal de chose avec les smart ponteurs.
Par contre je suis d'accord pour dire qu'il serait bon d'ajouter à cela la notion d'ownership aux pointeurs. J'ai d'ailleurs pour projet d'implémenter des classes de ce style à l'avenir. Mais pour le moment je manque de temps pour le faire (je le fais durant mon temps libre).

*Defective metaprogramming facilities

*Unhelpful standard library
Encore un trux sujet à débat... Encore une fois, comme pour le fait que le standart ne définit pas de norme au nivreau binaire, il y a du pour et du contre. C'est vrai que la librairie standart n'est pas aussi complète qu'on pourrai l'espérer, mais en même temps je n'ai surement pas envie d'y voir intégrer tout et n'importe quoi non plus (et surtout pas de GUI!!!).

*Defective inlining
Comme dit plus haut, c'est vrai que le mode d'inclusion n'est pas "optimal". A part ça...

*Implicitly called & generated functions
Le but de ces appels implicites est de simplifier la syntaxe. Est-ce un mal? Puis avec un debuggueur, on arrive toujours à savoir s'il y a eu des appels implicites. Enfin, je dirai qu'un IDE performant serait à même de nous aider pour ce genre de chose.

Bon voilà un bien long post. Tout ça pour dire que le C++ est un langage qui a des qualités et des défauts. Après c'est une question de gouts. Mais il faut admettre que ce n'est pas un langage ultime en soi. Cependant, il faut aussi mettre cela en perspective et voir d'ou viens ce langage, à savoir qu'il est bien moins récent que beaucoup d'autres langages et a hérités de certaines faiblesses des langages de l'époque (et du C en particulier). Mais il ne faut pas perdre de vue non plus que c'est un langage qui continue d'évoluer et que les prochaines évolutions se proposent de corriger certains des problèmes évoqués dans l'article cité. Quand aux autres, je suis plus que tenté de dire que l'auteur de cet article fait quand même preuve d'une sacré bonne dose de mauvaise foie. (Je suis en désaccord TOTAL avec ce qu'il dit sur au moins la moitié des sujets.)

18/11/2007, 02h01
eclesia

Etant géomaticien et developpeur je m'interesse a mes outils.

Je vous propose ce lien qui fait un comparatif sérieux de deux outils.
- C++ : Apache + MapServer s'appuyant sur les librairies GDAL
- Java : Tomcat + GeoServer s'appuyant sur les librairies GeoTools

Ces deux logiciels sont presque identique en fonctionnalité et leur finalité est identique. L'un (MapServer) beneficit d'un gros avantage d'experience (car plus ancien) et de la puissance des librairies GDAL (utilisé par les logiciels SIG les plus renommés). Quand a Geoserver et GeoTools la communauté est bien plus réduite.

Plutot que critiquer vise versa les faiblesses de l'un sur des points précis, c'est un cas concret de mise en pratique. Ces logiciesl sont des applications pour serveur qui utilisent des bases de données, des fichiers tres volumieux (pouvant depasser facilement le Giga) et de grand nombre de connexion simultanées.

http://www.foss4g2007.org/presentati...bstract_id=120

Ce document est officiel est n'a rien d'une plaisanterie, de plus je le trouve objectif et il montre les defauts des deux.

Ce que je cherche a montrer c'est que la jvm progresse serieusement de version en version. Et a partir de la 1.5 je trouve deplacé de considéré java comme lent par rapport au C dans une application complete et pratique. les resultats sont equivalants.
18/11/2007, 12h25
Kujara

Citation:

Envoyé par eclesia

Ce que je cherche a montrer c'est que la jvm progresse serieusement de version en version. Et a partir de la 1.5 je trouve deplacé de considéré java comme lent par rapport au C dans une application complete et pratique. les resultats sont equivalants.

Cette mauvaise foi de ouf >.<

"Dans UN exemple d'application precis, java et c++ ont les même performances".

Dans beaucoup d'autres cas, c++ defonce allegrement Java.

Et dans beaucoup d'autres cas encore, Java defonce allegrement c++.

ARRETEZ DE COMPARER LES PERFS. C'est pas comparable, point barre.
18/11/2007, 14h01
pseudocode

Citation:

Envoyé par Kujara

ARRETEZ DE COMPARER LES PERFS. C'est pas comparable, point barre.

A partir du moment ou 2 programmes C++ et Java fournissent le meme service, on peut les comparer. Maintenant, ce qu'il faut faire rentrer dans la tete des gens c'est que le résultat de la comparaison n'est pas une fonction linéaire universelle du genre: "Langage A" est X fois plus rapide/lent que "Langage B".

Mon avis c'est quand meme qu'en performance pure (operations par seconde) le C++ est (bien) meilleur que Java. Mais on ne recherche pas toujours la performance (dans un premier temps). Mon mantra c'est:

Java = first "Make it work", then "Make it fast".

C++ = first "Make it fast", then "Make it work".

Ou en d'autre terme, a la moitié du temps de développement du projet, j'aurais:
- un programme Java qui est complet mais qui est lent
- un programme C++ qui est rapide mais qui n'est pas complet
18/11/2007, 14h46
eclesia

Citation:

Envoyé par Kujara

Cette mauvaise foi de ouf >.<
"Dans UN exemple d'application precis, java et c++ ont les même performances".
Dans beaucoup d'autres cas, c++ defonce allegrement Java.
Et dans beaucoup d'autres cas encore, Java defonce allegrement c++.

Tu preches pas une religion la, donne des arguments ou des documents.

Ce n'est pas UN cas. c'est des actions diverses que font ces logiciels, je me repete, on juge l'ensemble de la technologie :

Citation:

Ces logiciesl sont des applications pour serveur qui utilisent des bases de données, des fichiers tres volumieux (pouvant depasser facilement le Giga) et de grand nombre de connexion simultanées.

Est ce que j'ai parlé de performance sur une action précise? non.
Est ce que j'ai dit java>C++ ? non
Est ce que j'ai dit C++>java ? non

Je suis tombé sur un document au hasard de mes recherches et qui m'a paru bien approprié au debat, alors je vous en fait part, ca va pas au dela. C'est bien l'esprit d'opposition, mais faut un minimum d'argument, la tu rale pour rien.

pour une fois qu'on a un document qui compare 2 technologies different sur le meme objectif et qui montre au final un resultat comparable au niveau des performances générales. Ca veut dire ce que ca veut dire.
18/11/2007, 16h41
Kujara

Citation:

Envoyé par eclesia

pour une fois qu'on a un document qui compare 2 technologies different sur le meme objectif et qui montre au final un resultat comparable au niveau des performances générales.

Lets try again.

"Ma 206 est meilleure qu'une F1 parcequ'elle negotie plus vite un rond point serré en ville..."

Cette phrase est completement stupide. Et pourtant c'est un peu ce que tu raconte.

La 206 est une voiture de ville, la F1 est faite pour circuit.

Les performances des 2 ne sont pas comparables.

Même principe pour le debat qui nous concerne.

Java est fait pour certaines applications, c++ pour d'autres.

Pour les applications en commun, la performance finale depends de comment c'est implémenté, comment c'est optimisé, ce que ça fait, pas vraiment du language.
18/11/2007, 17h02
eclesia

Citation:

Java est fait pour certaines applications, c++ pour d'autres.

les terrains qu'en ville ou que sur circuit sont rares. Donc ce comparatif montre le resultat en terrain semi-circuit si tu preferes.

... cet echange devient pitoyable ... j'arrete la.
19/11/2007, 17h01
koala01

Citation:

Envoyé par pseudocode

Faut dire aussi que la JVM est codée en C/C++, alors forcément faut pas attendre beaucoup d'efficacité... :mrgreen:

Méfie toi de ce genre de remarque...

Sinon, tu trouveras toujours quelqu'un qui poussera le raisonnement à l'extrême:

Citation:

Le premier compilateur C++ a été créé avec un compilateur C, qui lui même a été créé en assemble...

Moralité: codons en assembleur pour être efficace :D
19/11/2007, 17h15
pseudocode

Citation:

Envoyé par koala01

Méfie toi de ce genre de remarque...

C'etait juste une remarque humoristique pour répondre au troll de gorgonite. ;)

Voir 40 message(s) de cette discussion en une page