Discussion :

[++gib]

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.

Il est malhonnête de tronquer les phrases pour en inverser le sens.
La phrase etait
"Je pourrais par exemple critiquer Java en parlant de javascript,
ce qui ne serait pas malin."
Ce qui signifie que java et javascript n'ont effectiivement rien a voir:
une vague rssemblance syntaxique, et quelque concepts communs.
Alors arrêtez de dire que je n'ai rien compris et relisez vous.

La notion d'objet suffit à elle seule pour radicalement changer la façon
d'aborder la programmation, ce qui suffit a faire de C++ un langage très
différent de C. Mais il est plus facile de tout mettre dans le même panier.
Mais C++ est bien que cela, car il permet de programmer selon 3 paradigmes.
- full procédural
- full objet
- générique. Ce dernier point est passionant mais il n'est jamais abordé ici
car coté Java, c'est le trou complet de ce coté là.

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'utilisateur bien avancé !! Il est mort, mais on lui dit que c'est normal.
Vous venez vous même de citer un exemple un cas ou il n'y a aucun rattrapage,
juste la constatation d'un problème. CQFD

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.

Oui, mais pas nécessairement PAS critique. En fait vous n'en savez rien.

Votre argumentation s'auto-détruit (en vol)
Le fait de supposer que le module est déconnectable indique que
l'erreur est prévue. On tombe bien dans le domaine d'application
que je préconise pour les exceptions. Merci l'aller dans mon sens.
Or vous parlez également d'erreur imprévue : comment un évênement imprévu
peut engendrer une réaction appropriée prévue ?
C'est illogique.
Ou il existait une réponse à une situation prévue, et l'erreur a été de ne pas la
mettre en oeuvre, ou on n'avait pas de réponse car l'erreur était imprévue.
Dans les deux cas, les exceptions ne peuvent pas nous sauver.

Les exception sont un bon outil, pas un outil magique !

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++.

La corruption de données n'a jamais été un défi pour moi,
et je refuse (avec beaucoup d'autres) que l'efficacité de ce que j'écris soit dégradée
parceque c'est un problème pour d'autres.
J'ajouterais une fois de plus pour cette catégorie de personnes
qu'un programme faux est faux, dans tous les langages du monde.
Le fait d'avoir une bonne protection mémoire n'empêche pas les mauvaises
surprises, et ne dispense pas de corriger.

Vous voulez parler des threads ? Je suis à l'écoute.

[Clement Cunin]

Vous voulez parler des threads ? Je suis à l'écoute.

Non, tu n'es pas a l'ecoute.

Je pense que tu n'as jamais programmé une application qui devait imperativement fonctionner, quelque soit les condition. Je comprends pas pourquoi tu t'obstine a vouloir arreter la totalité d'une application lorsqu'une petite parti identifiable s'avert defectueuse. (Comme si une voiture refusait de demarrer apres avoir fait une tache sur la banquette arrière) Je trouve bien pretencieux de ta part de dire que ton application que tu viens de faire marchera dans 100% des cas... Moi je prefere concevoir mon application, la tester affin quel passe tous mes tests, et dire, au cas ou, meme si j'ai laissé passé une erreurs, j'ai pris un maximum de précaution pour que ca se passe le mieux possible. Si mon application, meme lègerement buggé continue a être utilisable le temps que je trouve/corrige l'erreur, c'est regretable, mais pas aussi catastrophique que d'avoir fournit au client un programme qu'il ne plus utilisé jusqu'a ce que j'intervienne .


Pour finir, Tu me reproche d'avoir couper une de tes phrases... mais je te ferais remarquer que Java n'a STRICTEMENT RIEN a voir avec javascript
omparer Java et Javascript n'a pas plus de sens que de le comparer avec Cobol, Lisp, oCaml, perl, rebol ou qui que se soit !
En revanche, C++ apporte une dimension supplémentaire au C, ces 2 langages sont très proche, on en tire les même avantage et inconvénient !

[++gib]

Vous voulez parler des threads ? Je suis à l'écoute.

Non, tu n'es pas a l'ecoute.

Ah bon ... Un peu trop coriace ?

Je pense que tu n'as jamais programmé une application qui devait imperativement fonctionner, quelque soit les condition. Je comprends pas pourquoi tu t'obstine a vouloir arreter la totalité d'une application lorsqu'une petite parti identifiable s'avert defectueuse.
(Comme si une voiture refusait de demarrer apres avoir fait une tache sur la banquette arrière)

Je ne veux pas l'arrêter, je suis simplement conscient qu' elle peut s'arrêter
toute seule lorsque les conditions sont défavorables.
Lorsqu'on a affaire à un bug
(ie: quelque chose de réllement 'imprévu), le gestionnaire d'exceptions
ne sait pas si c'est une tache sur la banquette ou un niveau d'huile à zéro
(Dans un cas ce n'est pas la peine de s'arrêter, dans l'autre, on le doit.)
Vous pensez qu'on peut systématiquement continuer en mode dégradé,
sous le prétexte que le contrôle à été rendu à un gestionnaire d'exception,
vous vous trompez. Le problème n'est plus d'avoir la possibilité
de faire quelque chose, mais savoir QUOI faire.
Dans le cas des bugs, si on le savait, les ordinateurs seraient intelligents et cette discussion
n'aurait pas lieu d'être.
Si on ne le sait pas quoi faire on sort du domaine ou les exceptions sont utiles et
celles-ci offrent donc une impression de sécurité trompeuses.
Je m'empresse de dire que le programmeur qui a cette impression en est pleinement
responsable, il ne s'agit nullement ici d'un défaut du concept "exception".

Je trouve bien pretencieux de ta part de dire que ton application que tu viens de faire marchera dans 100% des cas...

Ca alors ! La dernière fois vous avez coupé une de mes phrases pour en inverser le sens
, maintenant voici que je suis crédité de propos jamais tenus !

Moi je prefere concevoir mon application, la tester affin quel passe tous mes tests, et dire, au cas ou, meme si j'ai laissé passé une erreurs, j'ai pris un maximum de précaution pour que ca se passe le mieux possible. Si mon application, meme lègerement buggé continue a être utilisable le temps que je trouve/corrige l'erreur, c'est regretable, mais pas aussi catastrophique que d'avoir fournit au client un programme qu'il ne plus utilisé jusqu'a ce que j'intervienne .

Tout le monde fait comme cela. Tout le monde essaie de limiter la portée des bugs
par tous les moyens offerts par le langage. Je rappelle que les exceptions n'augmentent
pas les possibilités de traitement, elle permettent seulement de réaliser ceux-ci
plus confortablement.

Pour finir, Tu me reproche d'avoir couper une de tes phrases... mais je te ferais remarquer que Java n'a STRICTEMENT RIEN a voir avec javascript
omparer Java et Javascript n'a pas plus de sens que de le comparer avec Cobol, Lisp, oCaml, perl, rebol ou qui que se soit !
En revanche, C++ apporte une dimension supplémentaire au C, ces 2 langages sont très proche, on en tire les même avantage et inconvénient !

Absolument d'accord, rien à voir. Ce n'est que la troisième fois que je le dis.
Sauf que dans la tête des gens, javascript commence par "java" comme C++
commence par "C", la syntaxe est vaguement identique, ça parle vaguement
de classe etc..
C++ apporte effectivement une dimension supplementaire à C, et une belle :
on a les mêmes avantages (performances), mais très peu des inconvénients
(approche de + haut niveau, meilleure sécurité (si-si !), exceptions,
possibilité d'utiliser les pointeurs là ou ils sont réellement nécessaires, E/S sécurisées ,
généricité qui renforce le typage sans perte de performances et permet d'avoir une
très belle bibliothèque de composants (STL), modélisation objet qui change totalement
le mode de résolution des problèmes, et j'en passe)

Il y a un véritable "saut quantique" entre C et C++ et les gens qui ont "calé" sur
C ont tord de ne pas s'intéresser à C++, c'est une autre dimension. Pour être
concret, il me semble que ça fait une éternité que je n'ai plus géré la mémoire
"a la main" : les conteneurs standards le font très bien, avec toute la souplesse voulue
et des perf optimales.
Vous n'es pas à l'aise avec les pointeurs ? Utilisez des vector<> et vous serez averti si
vos indices dépassent les bornes. Mais si ça ne vous intéresse pas, vous n'êtes pas
obligé d'y avoir recours et vous pouvez même implémenter des politiques plus subtiles.

Dire après cela que C++ à les même inconvénients que C, c'est de l'ignorance
ou de la calomnie ou les deux.

[Clement Cunin]

Tu refuse de comprendre l'interet des exceptions dans un environnement protégé. On peut aller beaucoup plus loin que le simple "oups, ca plante".

Pour ton information, j'aime beaucoup faire des projets en C pour manipuler la mémoire, c'est vraiment simpas de pouvoir travaillé à l'octets pret. Dans le cadre de petit project, c'est rigolo !
En revanche qu'en je fais un gros projet, le fait de devoir toujours penser a libérer la mémoire est trop pesant.

[grishka]

Pour ceux qui ont eu le courage de suivre la discussion jusqu'ici, je vais essayer de présenter objectivement les différences entre c++ et java.

chaque technologie possède des avantages et des inconvénients dépendant du contexte d'utilisation. Vous trouverez ci-dessous une liste que j'espere assez exhaustive et qui
reprend les points abordé jusqu'ici.
N'hésitez pas à compléter ou corriger les erreurs.


GENERALITES

-java ne dipose pas de patrons de classes (templates), c++ oui. On peut s'en passer, mais les templates sont utilent pour les performances et un accroissement du typage. (en c++ vector<int> est un tableau d'entier, tandis que java.util.ArrayList est un tableau d'objets)

-c++ propose la surchage des opérateurs, java non

-java est fortement typé, c++ non (en java, un entier n'est pas un réel, sauf si on explicite la conversion)

-java gère l'allocation/désallocation de mémoire et ne permet pas d'accéder par défaut directement à la mémoire. Un new en c++ revoie l'adresse mémoire réelle, un new en java renvoie un identifiant de zone mémoire gérée par la jvm (d'ou la sécurité)

-java peut accéder directement à la mémoire (les DirectBuffer du nouveau package java.nio), mais dans ce cas la sécurité du code n'est plus garantie. La sécurité est cependant toujours plus élevée car pas d' arithmétique des pointeurs

-l'arithmétique des pointeurs en c++ pas en java (simplification très utile pour l'accès direct)

-passage des paramètres uniquement par valeur d'identifiant mémoire en java (donc pas de copie sur la pile), par copie et par référence en c++.

-java ne dipose que d'un mécanisme d'allocation dynamique alors que c++ propose aussi l'allocation sur la pile.

-java propose un ramasse-miette (garbage collector) qui marque les blocs libres et non-libres. Si un objet java n'est plus référencé, sa place mémoire sera réutilisée (mais on ne sait pas quand exactement)

-java intègre son méta-modèle accessible avec java.lang.reflect. (ex : pour créer des scripts qui ne nécessitent pas d'être recompilés à chaque fois)

-java charge les classes en mémoires à l'intant t si elle sont utilisées.

-java n'a pas besoin de fichier header, puisqu'il n'a pas de précompilateur (du coup pas de templates non plus...).

-une classe publique par fichier en java

-une classe compilée en bytecode est toujours facilement décompilable et lisible, pas en c++


EXCEPTIONS

-c++ et java propose un mécanisme d'exception (permettant de traiter le comportement exceptionnel d'un bloc d'instructions ou bien de traverser la pile d'appel des méthodes pour laisser la responsabilité du traitement à un niveau supérieur)

THREADS

-en java : threads gérés par la jvm et non le système d'exploitation. Gestion des sections critique, des attentes et notification, des groupes. Programmation simple par rapport à
unix ou windows.


SECURITE
-java permet de définir une politique de sécurité très fine dans une application de manière très simple
(ex un objet n'a pas le droit d'accéder au système de fichier, de se connecter à un serveur...).Le bytecode d'une classe externe est toujours vérifié par la JVM
-le modèle de sécurité de java n'a pas de faille connue (ce qui ne veut pas dire que l'implémentation de sun l'est...)


MODELE OBJET

-notion de composant logiciel en java (javabeans)
-pas d'héritage multiple (qui pose effectivement problème dans certains cas)
-notion d'interface en java, en c++ non
-toutes les méthodes java sont virtuelles, pas en c++
-les librairies java ont été développées autour de design patterns objets.
notamentparadigme MVC (Model-View-Controller) et Compite pour Swing, Decorateur pour la gestion des flux d'entrée/sortie, Factory, ...
Le développeur java bénéficie donc d'un environnement objet plus complet que c++. Attention : rien n'empêche d'utiliser les design pattern en c++ (c'est
même recommendé).


LIBRAIRIES STANDARDS
ici la standardisation permet de faciliter l'interopérabilité (communication entre processus sur des systèmes différents) et la portabilité

-C++ dispose de la librairie standard qui propose un découplage entre conteneurs de données et algorithmes manipulant les données (recherche, tri)

-java dispose de swing (composants d'interface utilisateur), jdbc (transparence d'accès à un SGBD), rmi (communication entre jvm distantes, indépendante de la localisation),
jaas (sécurité), jni (communication avec des composants natifs), jta (gestion des transactions), etc...

-j2EE : framework permettant de développer des applications n-tiers d'entreprise . On parle de composant
logiciels coté serveur (d'application) ou Entreprise-Javabeans (EJB). J2EE permet de découpler la logique métier de la technique (binding d'objet, persistance, transaction, etc...)
.NET permet de faire tout ca mais il n'est standard que sur la plate-forme Windows...


CONCLUSION

- java est donc un langage simple (ce qui ne veut pas dire simpliste) optimisé pour le développement rapide et spécialisé pour le développement d'applications web distribuées d'entreprise.
L'avantage de java réside avant tout dans les librairies dont il dispose.

- c++ est un langage performant générant un code natif optimisé, plutot destiné aux applications temps-réel (simulation, jeux vidéo) et à la programmation système

NB : en java, on peut effectivement obtenir des performances très proche du code natif, mais souvent au détriment du code qui devient moins lisible et moins objet
. Je travaille sur un projet personnel de moteur 3D temps réel en java et opengl. J'obtient environ 80-90% des performances du c++ optimisé sans avoir
sacrifié mon modèle objet. Certe des optimisations triviales comme la gestion d'un cache plutot qu'une allocation dynamique aléatoire est plus que souhaitable
en java (regardez les serveurs d'application java). Je travaille également sur une application web distribuée d'entreprise (mon gagne pain cette fois!). La rapidité de développement, la
qualité et la maintenabilité sont des contraintes importantes. Le C++ ne permettrait pas d'obtenir la même qualité pour un temps de développement donné. Meme avec .NET, on programme en Visual
Basic ou c# (ce dernier étant plus une politique commerciale qu'une aide au développeur). Développer en C++ plutot qu'en java, revient à choisir la ferrari pour rouler plus vite dans les bouchons.
Le goulot d'étranglement est internet, pas java.

Par contre C++ est toujours très attrayant si on aime les templates, la surchage d'opérateurs, la gestion de la mémoire.
Dans le domaine particulier des jeux vidéos, je pense qu'il faut choisir entre développer un jeu avec des performances inégalées (C++) ou des performances moindres (80% en moyenne) avec des
outils très pratique (la gestion des scripts XML avec java c'est l'extase).

[Elrond]

Grégory Picavet:

Juste quelques remarques concernant le resume:

Preciser que l'allocation dynamique C++ n'est pas sure en elle-meme. Elle necessite beaucoup d'attention pour eviter des faille de securite.

Ensuite, Java n'est pas utilise que pour des application Internet. Dans le cas d'une application interne, et pas forcement reseau, le goulet d'etranglement n'existe plus. Neanmoins, rares restent les applications qui demandent un niveau de performance tel que la difference entre une application Java et une application C++ soit un probleme pour l'utilisateur.

Pour finir, une question. Quand tu dis que tu obtiens des perf de 80 a 90% de celles du C++ avec Java, cela est-il toujours en passant par la machine Virtuelle ou apres avoir compile en code natif. Et dans le cas ou c'est en utilisant la machine virtuelle, as-tu essaye de compiler en code natif pour avoir une autre estimation des performances?

[Clement Cunin]

Je suis completement d'accords avec Grégory Picavet, je valide donc cette synthèse...

et Compite pour Swing,

Faute de frappe ?

-java peut accéder directement à la mémoire (les DirectBuffer du nouveau package java.nio), mais dans ce cas la sécurité du code n'est plus garantie. La sécurité est cependant toujours plus élevée car pas d' arithmétique des pointeurs

J'ai pas eut le temps de m'interressé a ce fameux package, donc je sais pas...

Et j'ajouterais :
- Java propose un environnement d'execution protégé, C++ non.
(Un certain nombre des points cités étant la caracteristique d'un environement protégé, c'est donc un peu redondant mais toujours utile de le précisé, c'est le but de Java )

[grishka]

Pour finir, une question. Quand tu dis que tu obtiens des perf de 80 a 90% de celles du C++ avec Java, cela est-il toujours en passant par la machine Virtuelle ou apres avoir compile en code natif. Et dans le cas ou c'est en utilisant la machine virtuelle, as-tu essaye de compiler en code natif pour avoir une autre estimation des performances?

Non, c'est toujours du bytecode . Je testerai bien en natif, mais il faut un compilateur natif jdk1.4.1 que je n'ai pas.

Je pense que ce résultat dépend de la machine et de l'application.
Les applications sont celles qu'ont peut trouver sur le site
http://nehe.gamedev.net.
J'ai remarqué que sur un Pentium 4 avec ATI RAGE 128 + 8Mo j'obtient 80%-90%. Sur un AMD 1800+ avec GeForce 4 + 64Mo, j'obtient une image calculée par rafraichissement de l'écran ( pareil que c++ ). Dans un vrai jeu, il faut aussi tenir compte de l'IA, du moteur physique, des scripts, etc... Je vous signalerais dès que j'aurais un site web avec mon travail dans ce domaine (ce qui ne saurait tarder). Mais si vous souhaitez tester par vous même et pour prouver que ce n'est pas du pipotage :
http://web.hypersurf.com/~sully/OpenGL/DemoBox.html
http://chman-area.tuxfamily.org/index-fr.html

Citation:
et Compite pour Swing,

Faute de frappe ?

Oui! c'est le design pattern Composite

[++gib]

on a les mêmes avantages (performances)

faux !
La perte de performance lié à la gestion de la couche object n'est pas négligeable. L'appel d'une methode d'un object est incomparablement plus complexe qu'un simple appel de fonction en C.

Quelle ignorance ! Le surcoût de l'objet en mode compilé est extrèmement faible,
et je vais prouver que "l'incomparablement plus complexe" ne relève même
pas de l'exagération : c'est du délire.

Voici un petit code qui comporte une fonction ordinaire g() et une classe X
munie d'une méthode f(). Ces deux "routines" sont appelées dans main()
et reçoivent exactement la même
quantité d'information : l'objet support x pour f() , et également x, passé
explicitement pour g()

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
class X
{
    public:
    int f() ;
} ;
int X::f() 
{
    return 0 ;
}

int g(X& k) 
{
    return 0 ;
}

int main()
{
    X x ;
    
    x.f() ; // appel methode
   // ...
    g(x) ;  // appel fonction ordinaire
}

Voici maintenant le code génére pour g() (compilateur gcc, processeur PIII),

Code :

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

1
2
3
4
5
_Z1gR1X:
.LFB2:
	movl	$0, %eax
	ret

et le code pour f()

Code :

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

1
2
3
4
5
_ZN1X1fEv:
.LFB1:
	movl	$0, %eax
	ret

Je pense que tout le monde voit que c'est le même.

Voici le code d'appel de la méthode f()

Code :

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

1
2
3
4
5
6
	subl	$12, %esp
	leal	-1(%ebp), %eax
	pushl	%eax
.LCFI3:
	call	_ZN1X1fEv

et celui de g()

Code :

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

1
2
3
4
5
	subl	$12, %esp
	leal	-1(%ebp), %eax
	pushl	%eax
	call	_Z1gR1X

Bon, je pense que la démonstration est concluante. Un appel de méthode
coûte exactement ici 4 instructions machine, comme un appel de fonction,
alors arrêtons de délirer ou de répéter sans vérifier.
Pour être complet, il existe un cas ou l'appel de méthode est plus coûteux :
si cette méthode est virtuelle, le cout "grimpe" a 5 instructions (oops!),
mais on a une fonctionnalité supplémentaire : le polymorphisme,
qui a un intérêt énorme en technologie objet.

Techniquement, Le surcout provient de la nécessité de réaliser une indirection
via la table des méthodes virtuelles de l'objet support.

On remarque au passage qu'une fonctionnalité qui n'est pas utilisée
ne coûte rien en C++ (Ce qui n'est pas le cas en Java).

Code :

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

1
2
3
4
5
6
7
	leal	-24(%ebp), %eax
	movl	$_ZTV1X+8, -24(%ebp)
	subl	$12, %esp
	pushl	%eax
.LCFI3:
	call	_ZN1X1fEv

J'espère que tout le monde sera convaincu .. Le reste du modèle objet est
manipulé de la même façon. La manipulation d'un modèle objet
est certe complexe, mais n'a pas d'impact sur les performances en mode compilé
car le compilateur fait tout ce qu'il est possible de faire une fois pour toutes,
avant exécution.
En ce qui concerne Java, je ne connait pas le détail des opérations
faites par la JVM lors de la manipulation des objets mais il est facile
de comprendre qu'une partie du boulot est faite à l'execution.
Pour creuser la chose, il faudrait avoir le code source de la JVM
et y passer beaucoup de temps, ou demander à quelqu'un qui s'est
déjà interessé au problème.
Je constate simplement que ce c'est lent.

Tu refuse de comprendre l'interêt des exceptions dans un environnement
protégé. On peut aller beaucoup plus loin que le simple "oups, ca plante".

Pour me convaincre, il faudrait peut-être me donner une exemple dans
lequel on traite correctement une erreur totalement inattendue.

Pour ton information, j'aime beaucoup faire des projets en C pour manipuler
la mémoire, c'est vraiment simpas de pouvoir travaillé à l'octets pret. Dans le cadre de petit project, c'est rigolo !
En revanche qu'en je fais un gros projet, le fait de devoir toujours penser a libérer la mémoire est trop pesant.

Et bien oui, c'est pareil pour moi. (Et pour de très nombreuses personnes).
Le problème c'est que encore une fois, nous sommes censés parler de Java et
de ..... de .... de .... C++ ! (oui , gagné !).
Cet amalgame C/C++ est présent dans au moins 50% des interventions de ce
forum, c'est regrettable et ça temoingne de la quantité d'idées toutes faites qui
circulent.

La question de gestion mémoire est très différente en C++ de celle du C
car on n'en fait pratiquement plus (sauf si on programme des classes
de très bas niveau, ce que le programmeur moyen ne fait pas car il
s'appuie massivement sur des bibliothèques, toolkits, frameworks etc.).
En pratique, on utilise des conteneurs génériques
très bien faits qui la gèrent très bien. Le mécanisme de
construction/destruction fait le reste quelel que soit la complexité
de la structure de donnée mise en oeuvre.

Je le répète : le C, c'est l'assembleur du C++ .

[Marc Lussac]

Vous seriez bien aimable de recentrer le débat sur C++ versus Java pour ce sujet, parce que :

- C# Versus Java c'est ici :
http://www.developpez.net/forums/vie...=262725#262725

- .NET versus Java c'est ici :
http://www.developpez.net/forums/viewtopic.php?t=30401

Merci de votre compéhension.

[gregy]

Pour ma part d'accord avec Gregory + les petites rajoutes qui ont suivies... J'insiste également que java n'est pas uniquement utilisé que pour des application Web, même si tout est prévu pour en faire et que ca en fait un de ces domaines de prédilection.

Dire après cela que C++ à les même inconvénients que C, c'est de l'ignorance
ou de la calomnie ou les deux.

Quelle ignorance ! ...

etc etc et autres remarques du genre...

En synthétisant tes messages ++gib, java ne vaut pas la peine, sauf pour faire de 'petites' appli, tout ca pour une raison de performances (qui n'est pas tant justifiée, sauf sur l'arguement 'choc' des progs qui tournent sur des vieux pc's), et quelques petites raisons de philosophie qui te genent personnellement. Alors les remarques 'Quelle ignorance', 'calomnie' et on en passe, on peut te les renvoyer quand est à ce point là pas objectif.

Au fait on attend toujours l'explication à propos des différentes applications c++/java que tu aurait testé pour tirer tes conclusions sur java.

[++gib]

[quote]

Pour ma part d'accord avec Gregory + les petites rajoutes qui ont suivies... J'insiste également que java n'est pas uniquement utilisé que pour des application Web, même si tout est prévu pour en faire et que ca en fait un de ces domaines de prédilection.

Dire après cela que C++ à les même inconvénients que C, c'est de l'ignorance
ou de la calomnie ou les deux.

Quelle ignorance ! ...

etc etc et autres remarques du genre...

Je suis désolé d'avoir été aussi aggressif envers Clément et suis prêt à lui faire
des excuses si il le désire.

Sur le fond, je ne changerai rien.

Je remarque d'ailleursi que vous ne faite aucun commentaire sur ma dernière
démonstration. Je serais intéressé d'en avoir un.
Je rappelle également que je suis le seul a avoir pris la peine de produire
du code, afin de permettre à chacun de vérifier que je n'ai pas simplement colporté un
FUD de plus.

Code :

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

1
2
En synthétisant tes messages ++gib, java ne vaut pas la peine, sauf pour faire de 'petites' appli, tout ca pour une raison de performances (qui n'est pas tant justifiée, sauf sur l'arguement 'choc' des progs qui tournent sur des vieux pc's), et quelques petites raisons de philosophie qui te genent personnellement. Alors les remarques 'Quelle ignorance', 'calomnie' et on en passe,  on peut te les renvoyer quand est à ce point là pas objectif.

Je vais répondre point par point
1) Intérêt de Java :
Il est grand dans certains domaines, très surestimé dans d'autres.
Effectivement, hors des cas ou ont doit faire migrer du code, on peut très souvent faire mieux avec C++. Mieux ne signifie pas plus facilement !
Je sais parfaitement (et je le comprend) que Java est ressenti comme étant facile,
et qu'il attire pour cela. Une question que cela pose est la suivante :
Doit on privilégier celui qui écrit le programme ou celui qui l'utilise, la facilté au résultat ?
En "bonne" logique économique qui ne se préoccupe que du profit à court terme,
la réponse est oui, si on regarde plus loin, c'est non.

J'ose espérer que ce forum concerne un peu la technique.

Depuis 10 que Java existe, pourquoi aucun des grands logiciels qui cohabitent sur nos machines ne sont écrits en Java (OS, Traitements de texte, BD, Tableurs, etc).
Pourquoi tous les prog Java qui on à faire autre chose que de la présentation de données
s'appuient-ils sur des couches écrites en compilé ?

Je sais qu'on va me tomber dessus en me parlant des tel ou tel système de gestion développé pour ou par telle grosse boîte (la taille de la boîte indiquant que, manifestement,
ce n'est pas du bidon).
Alors je poserai la question : en quoi est écrit le moteur qui anime tout ça ?
L'application de gestion typique, c'est une interface graphique (dont les couches basses sont en C) qui envoie des requêtes SQL à un SGBD, reçoit et filtre les réponses et les
affiche.
Bon soit, ça présente un intérêt dans ce cadre sous certaines contraintes. Mais
ce n'est pas avec ça que l'on peut prétendre à un statut de langage généraliste.
Je n'ai jamais rien dit d'autre.

2) En ce qui concerne les vieux PC lents:
je ne les ai jamais considéré comme les "arguments choc" dont vous parlez, relisez moi. Les machine rapides sont ralenties par Java
dans le mêmes proportions que les lentes. Si on utilsait Java réellement comme un
langage généraliste (ce qui n'est pas le cas, les gens ne sont pas fous) on
retournerait à l'époque des PC 133Mhz.

3) Mon objectivité :
J'ai bien envie de me fâcher encore. Je suis ici le seul à produire une preuve de ce
que j'avance, et on critique mon objectivité. Vous feriez mieux de répondre
à mes arguments autrement, ce serait plus crédible.

Au fait on attend toujours l'explication à propos des différentes applications c++/java que tu aurait testé pour tirer tes conclusions sur java.

J'avais lancé une proposition de Benchmark, mais sans echo jusqu'a présent.
C'est chose faite. J'aimerai que les personnes intéressées se manifestent.
Je propose de poster ici un code source C++ et Java, que chacun pourra mettre en oeuvre.
et vérifier. Je pourrai en outre bénéficier de l'expertise des programmeurs Java (ou autre)
qui m'indiqueront d'éventuelles améliorations.
Je souligne qu'il est important de tester du code connu, sans quoi toute conclusion est
impossible. J'ai par exemple vu passer sur ce forum une phrase du style
"oui, le programme XXX est aussi rapide que YYY, etc.."
Désolé, mais comme on ne sait pas ce que font réellement ni XXX ni YYY
c'est du vent.

[grishka]

-100% d'accord avec toi ++gib sur l'indirection supplémentaire de la table des méthodes virtuelles. En java toutes les méthodes sont virtuelles, donc pas d'optimisation à ce niveau.
Mais il faut savoir que java a été concu par souci de simplicité (entre autres). Bien sur cela peut poser des pbl, voire dérouter pas mal de gens :

y'a des trucs que j'aurais aimé dans java :
-les templates du c++ qui permettent de faire ce qui ressemble à du polymorphisme statique, pour parler objet
-le passage par référence du c++ (c# le propose)
-surcharge des opérateurs (c# le propose)
-l'héritage multiple. La solution de java est assez restrictive mais je la trouve meilleure que c++ qui s'en fout complétement (à moins de faire de l'héritage virtuel, mais ca devient vite le bordel). Des mécanismes seraient possible pour améliorer java.

Cela étant, si les concepteurs de java ne l'ont pas fait, c'est certainement pour des raisons d'incompatibilité avec leur cahier des charges. Conflit avec la sécurité, transgression du modèle objet, spécificité du langage, etc...
Aahh! si seulement on avait ce petit bijou qu'est la STL du c++ en java...


trucs un peu bizarre de java:
-finalize() dans les objets pas bien défini et pas bien utilisé en plus...

trucs que j'aime bien en java par rapport au c++ (sans tenir compte des librairies):
-méta modèle (pour diriger son appli avec des scripts par ex)
-Les threads. Bon ok c'est plus en fonction de l'OS pour le c++, mais il faut avouer que c vraiment bien joué.
-Sur les exceptions, je préfère finally pour désallouer des ressources plutot que les destructeurs appelés automatiquement (et encore si les objets sont sur la pile) lors qu'on sort d'un catch. En tout cas son existence est nécessaire puisque pas d'allocation sur la pile en java.



autre point : si tu veux comparer le code c++ et java concernant de la synthese d'image en 3D temps réel, je t'invite à regarder les liens fournis plus haut. En tout cas java ne sert pas à faire que des jeux de cartes et j'affirme qu'un jeu comme quake 3 en java est sérieusement réalisable. avec 80% de la rapidité en c++, certes, mais avec un modèle objet plus complet et un temps de développement réduit. De plus dans ce domaine,
ca dépend aussi si on se sent plus à l'aise en C++, java ou Delphi

J'en profite pour donner un ou deux trucs pour ceux qui veulent faire de l'optimisation en java :

-avoir une bonne modélisation, ca évite les usines à gaz (voir les Design Patterns, faire un peu de conception UML ca aide). Bon c'est de loin le plus difficile!
-La condition numéro un à remplir pour obtenir de bonnes performances dans un programme java temps réel est d'utiliser l'allocation dynamique avec parcimonie et de coder un allocateur sous forme de pool (comme les ejb).
J'obtiens une optimisation de 50% à 300% selon les cas.
en effet ca evite de fragmenter la mémoire du garbage collector si on a bcp d'allocation/desallocation. En plus un new doit certainement se synchroniser avec le GC pour obtenir de la mémoire, d'ou perte temps...
-Meme ordre d'optimisation : éviter le création d'objet temporaires. Le c++ dispose de la pile et du passage par référence constante, ce n'est pas une raison pour coder de la même facon en java. Bref il vaut mieux créer un objet de travail sur le tas, faire les opérations dessus, l'utiliser puis le libérer.

Code :

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

1
2
3
4
5
6
Float4 res = Float4.Add(a, Float4.Scale(Float4.Sub(b-a),t)); // 3 new

Float4 res = new Float4(b);
res.sub(a);
res.scale(t)
res.add(a); //1 new

Bon ok c'est pas aussi beau qu'en c++ et ca ressemble un peu à de l'assembleur... mais c'est plus rapide et sans violer le concept objet.

Tiens au fait ce serait super des sujets sur "optimisation en java", "java et les jeux vidéos", "performance et modèle objet" dans ce forum. Je suis sur qu'il y a bcp à dire.

[++gib]

Pour ceux qui ont eu le courage de suivre la discussion jusqu'ici, je vais essayer de présenter objectivement les différences entre c++ et java.

chaque technologie possède des avantages et des inconvénients dépendant du contexte d'utilisation. Vous trouverez ci-dessous une liste que j'espere assez exhaustive et qui
reprend les points abordé jusqu'ici.
N'hésitez pas à compléter ou corriger les erreurs.

Je ne peux que louer votre effort de synthèse.
Je suis plutôt d'accord avec l'ensemble de ce qui y est dit, mais voudrais
corriger quelque points.

-java est fortement typé, c++ non (en java, un entier n'est pas un réel, sauf si on explicite la conversion)

En C++ non plus un entier n'est pas un réel !!!!
Qu'est ce que c'est que cette histoire ?

Test Java

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
class X
{
	public  void f()
	{
		double x = 1.0 ;
    	int i = 2 ;
    
    	x = i ;
    	i = x ;
	}
}

Resultat: (avec JDK sun linux)

Code :

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

1
2
3
4
5
6
7
x.java:9: possible loss of precision
found   : double
required: int
        i = x ;
            ^
1 error

Test C++ (avec gcc linux)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class X
{
public:
    void f()
	{
    	double x = 1.0 ;
    	int i = 2 ;
    
    	i = x ;
    	x = i ;
    
    }
} ;

Résultat:

Code :

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

1
2
3
4
x.cpp: In member function `void X::f()':
x.cpp:9: warning: assignment to `int' from `double'
x.cpp:9: warning: argument to `int' from `double'

En fait, les deux langages sont fortement typés, sauf que
(comme vous l'avez dit) les conteneurs génériques de C++
permettent de conserver un typage normal alors que Java relâche le typage
lorsqu'on utilise des conteneurs permettant de stocker en vrac n'importe
quel type d'objet.

-java peut accéder directement à la mémoire (les DirectBuffer du nouveau package java.nio), mais dans ce cas la sécurité du code n'est plus garantie. La sécurité est cependant toujours plus élevée car pas d' arithmétique des pointeurs

Je prédis un "brillant" avenir à ce paquetage. Il est en contradiction
avec la philosophie de Java.

-l'arithmétique des pointeurs en c++ pas en java (simplification très utile pour l'accès direct)

Pouvez vous expliquer les dangers de l'arithmétique et cette simplification ?

-passage des paramètres uniquement par valeur d'identifiant mémoire en java (donc pas de copie sur la pile), par copie et par référence en c++.

Donc possibilité de copie ou non en C++, au choix.

-java intègre son méta-modèle accessible avec java.lang.reflect. (ex : pour créer des scripts qui ne nécessitent pas d'être recompilés à chaque fois)

Les gens intéressé par l'utilisation d'un méta modèle en C++ peuvent se pencher
le fonctionnement de Qt (http://www.trolltech.com)
Celui ci offre (gratuitement) un précompilateur qui extrait un méta modèle
du code source. Tout Qt est basé dessus et ça marche parfaitement bien.
Si vous utilisez KDE, vous mettez en oeuvre ce méta modèle a chaque seconde,
sans le savoir puisqu'il est à la base du système signal-slot.

-java n'a pas besoin de fichier header, puisqu'il n'a pas de précompilateur (du coup pas de templates non plus...).

Les templates ne sont PAS gérés par le pré-processeur
(ni par un pré-compilateur). Ils sont gérés par le compilateur.

-en java : threads gérés par la jvm et non le système d'exploitation. Gestion des sections critique, des attentes et notification, des groupes. Programmation simple par rapport à
unix ou windows.

Vrai et faux. Java offre aussi la possibilité d'utiliser les threads natifs
(source: JDK). Je pense que les green-threads doivent avoir des
inconvénients dans certains cas.
Il existe de nombreuses bibli de threads en C++.
Je recommande Jthreads++, (http://www.iona.com/devcenter/orbacus/jtc.htm)
qui fournit une implémentation des threads Java-like très élégante,
tout aussi facile à utiliser que celle de Java.

Ceci montre que la véritable puissance d'un langage est avant tout
d'être extensible.

Je travaille sur un projet personnel de moteur 3D temps réel en java et opengl. J'obtient environ 80-90% des performances du c++ optimisé sans avoir
sacrifié mon modèle objet. Certe des optimisations triviales comme la gestion d'un cache plutot qu'une allocation dynamique aléatoire est plus que souhaitable
en java (regardez les serveurs d'application java). Je travaille également sur une application web distribuée d'entreprise (mon gagne pain cette fois!). La rapidité de développement, la
qualité et la maintenabilité sont des contraintes importantes. Le C++ ne permettrait pas d'obtenir la même qualité pour un temps de développement donné.

Je suis intéressé par vos chiffres et il me laissent un peu perplexe.
Comme je ne vous prends pas pour un menteur et que je suis plutôt sûr de
mes mesures (qui ne collent absolument pas avec les votres), j'aimerai
savoir ce que fait votre application, et ce que vous avez mesuré.

Mon inquiétude vient de l'utilisation d'open GL.

Il est notoire que les calculs 3D coûtent cher et doivent
donc représenter une part importantes des temps d'exécution.
Je me demande donc si vous n'avez pas mesuré les performance d'open GL
(qui ne doit pas être écrit en Java, et peut d'ailleurs largement reposer
sur le matériel) au lieu de celle de votre code.
Avez vous profilé l'appli pour voir ou se passe le temps d'exécution ?

Bref, l'histoire de la mouche dans un couloir de TGV et dont
le GPS indique qu'elle vole à 280 Km/h.

Qu'en pensez vous ?

[gregy]

J'avais lancé une proposition de Benchmark, mais sans echo jusqu'a présent.
C'est chose faite

Excuses-moi mais là je reste sur ma faim... Un benchmark, ca se fait avec des chose comparables. Ton benchmark, tu le fait avec des choses, qui n'existent pas OU ou que tu crois ne pas exister en java. Merci pour ton benchark... Non, forcément ca n'existera pas un Os en java... Si tu parlais de ton code en asm, c'est pas ça qui va me convaincre non plus, qui plus est, il n'est pas complet, on ne voit que le détail en c++... Enfin pour moi toutes ces affirmations ce n'est que du vent

Pourquoi ne pas faire un benchamark sur ce qui est comparable? Sur des choses qui existent?

Il est grand dans certains domaines, très surestimé dans d'autres.
Effectivement, hors des cas ou ont doit faire migrer du code, on peut très souvent faire mieux avec C++. Mieux ne signifie pas plus facilement !
Je sais parfaitement (et je le comprend) que Java est ressenti comme étant facile,
et qu'il attire pour cela. Une question que cela pose est la suivante :
Doit on privilégier celui qui écrit le programme ou celui qui l'utilise, la facilté au résultat ?
En "bonne" logique économique qui ne se préoccupe que du profit à court terme,
la réponse est oui, si on regarde plus loin, c'est non.

Pourquoi tous les prog Java qui on à faire autre chose que de la présentation de données
s'appuient-ils sur des couches écrites en compilé ? ...

Alors je poserai la question : en quoi est écrit le moteur qui anime tout ça ?

Java est totalement capable de gérer de aplli autres que de la présetation... Alors la seconde remarque, je commence à trouver ce genre de propos complètement ridicules... : Peut-être devrait tu directement programmer en asm, c'est quand même la finalité non? En plus tu seras sûr de tout pouvoir contrôler... Ou encore, coder bits par bits, parce que, tout compte fait c'est à ca qu'on doit arriver? ... pfff

Pour ce qui est de la logique économique... Ben c'est à toi de voir... Le cours/moyen terme pourra faire en sorte que soit sur le marché (et avoir les parts de marché) en premier avec une appli de tres grande qualité dans une certaine technologie, avant d'autres mais qui au bout du compte auraient la même appli, mais soit disant '''BEAUCOUP''' plus performante, quelques années plus tard. (Non, je ne parles pas d'un OS ...)

J'ai bien envie de me fâcher encore. Je suis ici le seul à produire une preuve de ce
que j'avance, et on critique mon objectivité. Vous feriez mieux de répondre
à mes arguments autrement, ce serait plus crédible

.
Je vais pas me répeter c'est déjà dans la 1é remarque

[Elrond]

Excuses-moi mais là je reste sur ma faim... Un benchmark, ca se fait avec des chose comparables. Ton benchmark, tu le fait avec des choses, qui n'existent pas OU ou que tu crois ne pas exister en java. Merci pour ton benchark... Non, forcément ca n'existera pas un Os en java... Si tu parlais de ton code en asm, c'est pas ça qui va me convaincre non plus, qui plus est, il n'est pas complet, on ne voit que le détail en c++... Enfin pour moi toutes ces affirmations ce n'est que du vent

Ca tient du dialogue de sourd la!

Il est tres clair que le code asm n'avait absolument pas pour but de demontrer quoique ce soit par rapport a Java, mais de montrer que la difference entre C et C++ compile n'est quasiment pas different, ce qui donne des performances de base comparables (ca peut ensuite pas mal changer en fonction des fonctions supplementaires qu'on peut mettre en oeuvre en C++ comme les exceptions, ...). Cette partie la ne me semble pas etre completement du vent.

Maintenant, je suis d'accord, on a toujours rien vu concernant un benchmark valable de comparaison entre C++ et Java! Peut-etre ++gib devrait commencer a montrer quelque chose qui pourra ensuite etre adapte ou ameliore par d'autres.

[grishka]

comme tu viens de le démontrer, java est plus fortement typé que le c++ dans le sens ou il produit une erreur et pas un warning.
La relation "est un" est à prendre au sens objet, c'est à dire "peut se substituer à". En java, il faut effectuer un dynamic cast : int i = (int) 0.5f par ex, car c'est vu comme un transtypage (au sens objet), donc le typage java est plus strict.

------

arithmétique des pointeurs ca veut bien dire : si p1, p2 sont des pointeurs alors p1+p2 aussi, p1-p2, p1+1, etc... et donc permettent d'accéder à la mémoire un peu n'importe comment. En java, évidemment, ca n'a aucun sens. l'accès à la mémoire se fait par conteneur (avec get/set). D'ou un accroissement de la sécurité. De plus on peut convertir un tableau de type primitif en son équivalent DirectBuffer (et inversement) dans l'ordre natif des octets de la machine, de manière transparente.

Je prédis un "brillant" avenir à ce paquetage. Il est en contradiction
avec la philosophie de Java.

est-ce donc que tu reconnais que la philosophie de java est bonne est que le c++ n'a pas de brillant avenir? .Bon évidement c'est pas aussi simple. De plus, les buffer à accès direct ne sont qu'un cas particulier de ce package. Les entrès-sorties étaient le point faible de java. Le package nio permet de réaliser enfin des applications très performantes, capable de monter en charge. Le package io permet de gérer simplement la mémoire avec des performances qui sont bien connues (à cause du blocage avec les threads entre autres)...Le package nio, un peu plus complexe permet de gérer précisement les buffers sans blocage. Les domaines de prédilection de ce package, d'après les cas d'utilisation que l'on peut trouver dans les entreprises, sont les serveurs, le chargement des données en mémoire, etc...
Quant à la sécurité, je ne sais pas si elle est toujours garantie par rapport aux tiers, chose importante quand on travaille dans une architecture distribuée.

------

Les templates ne sont PAS gérés par le pré-processeur
(ni par un pré-compilateur). Ils sont gérés par le compilateur.

effectivement, je reconnais, j'ai dérappé. Je voulais juste distinguer les header de l'implémentation en c++, chose qui n'existe pas en java.
En fait le code d'un template n'est compilé que si on réalise une instance de ce template. C'est un peu le point faible car tant qu'aucune instanciation n'est faite, il n'y a aucun moyen de vérifier le type (à chaque techno son inconvénient bien sur).

pour ceux qui s'intéressent aux templates en java, il existe des projets en cours. http://igm.univ-mlv.fr/~forax/java/jlx/template/paper/Je crois que Sun, si ce n'est pas déjà fait, devrait s'inspirer de ces travaux de recherche qui sont très prometteurs.

Ceci montre que la véritable puissance d'un langage est avant tout d'être extensible.

A bon tu connais bcp de langage qui ne sont pas extensibles? Tu vois qu'il n'y a pas que les performances dans la vie. En plus sans java, JThread n'existerait pas, on peut donc reconnaitre que java propose de bonne idées en programmation.

Je suis intéressé par vos chiffres et il me laissent un peu perplexe.
Comme je ne vous prends pas pour un menteur et que je suis plutôt sûr de
mes mesures (qui ne collent absolument pas avec les votres), j'aimerai
savoir ce que fait votre application, et ce que vous avez mesuré.

Ok je n'ai peut être pas été clair. Je t'ai proposé des sites que tu devrais réellement visiter. Ce sont des portages en java des célèbres tutoriaux opengl du site nehe, le référence du genre. J'affirme qu'en moyenne, on peut s'attendre à obtenir 80 à 100% des performances du c++ optimisé. Maintenant dans l'application que je développe, je ne vais pas m'amuser à la faire en c++ pour le plaisir de faire du benchmark, je m'en fous. Dans mon appli, j'ai un rendu de paysage avec niveau de détail adaptatif, un rendu d'atmosphere par vertex shader, les modèles de personnages de quake 3, des arbres, des nuages 3D avec modèle physique réaliste, un moteur physique. Avec tout ca j'obtient une vitesse d'affichage acceptable pour le temps réel. J'ai fait le choix de java simplement par gout, et pour les possibilités de scripting.

Il est notoire que les calculs 3D coûtent cher et doivent
donc représenter une part importantes des temps d'exécution.
Je me demande donc si vous n'avez pas mesuré les performance d'open GL
(qui ne doit pas être écrit en Java, et peut d'ailleurs largement reposer
sur le matériel) au lieu de celle de votre code.
Avez vous profilé l'appli pour voir ou se passe le temps d'exécution ?

Evidemment la librairie opengl pour java est réalisée avec jni. Lors de l'exécution, le JIT optimise les accès comme si ils étaient en natif. Donc les appels de méthodes opengl se font à la même vitesse qu'en c++. Maintenant la perte de performance se fait dans la gestion de la mémoire, d'ou les optimisation que je donne. De plus, il est possible d'améliorer le système de chargement des textures avec nio.
Quant au profilage, ma foi, il est évident que le goulot d'étranglement est ici la capacité de la carte graphique. TOUS les calculs sont effectués par opengl, donc en natif.
Si je veux distribuer mon appli, il faut que je fournisse une dll pour windows, une librairie pour linux, pour beos, etc.. qui sont fournies

[gregy]

Ca tient du dialogue de sourd la!

Pas tant que ça. ++gib affirme avoir décrit un de ces benchmark, ainsi qu'une démonstration. A part celle de l'asm, je n'en voit pas d'autre, j'ai peut-être raté un post ou mal compris qq chose, dans ce cas je présentes mes plus plattes excuses... Enfin soit, mon message allait plus dans le sens qu'il manquait un vrai benchmark...

[masterfangorn]

Je pense pour ma part que la rapidité d'execution sera de moins en moins un problème, (avec la puissance croissante des ordinateurs et les améliorations nombreuses apportées au JRE et au langage lui même).

Aujourd'hui il plus d'actualité de confronter JAVA à C# par exemple, puisque le fond de commerce des deux est l'informatique distribuée et les services Web.

Pour les applications classiques, pas de problème il faut apprendre le C/C++ car des jeux, applications multimedia en JAVA ce n'est surement pas pour demain.

[++gib]

comme tu viens de le démontrer, java est plus fortement typé que le c++ dans le sens ou il produit une erreur et pas un warning.
La relation "est un" est à prendre au sens objet, c'est à dire "peut se substituer à". En java, il faut effectuer un dynamic cast : int i = (int) 0.5f par ex, car c'est vu comme un transtypage (au sens objet), donc le typage java est plus strict.

Bonjour Grégory
Ce n'est pas cool de pinailler. Le fait qu'une problème soit reporté comme
une erreur ou un avertissement depend simplement des options de compilation,
c-a-d des souhaits de l'utilisateur. On peut transformer le warning
gcc en erreur baveuse (option -pedantic-errors la bien nommée),
ou même n'avoir aucun rapport d'erreur si on le désire.
Ca n'a pas grand chose à voir avec le langage.
Ce qui est important c'est que la sémantique du langage fasse que le compilateur
puisse détecter un problème.
javac dit "problème potentiel" (il a raison, ce n'est pas
forcément un problème)
et gcc dit "attention, assignation d'un double à un int",
après c'est au programmeur de prendre ses responsabilités.

Pour la suite de ton intervention, je suis perplexe car
int i = (int) 0.5f ; est exactement ce qu'on *pourrait* écrire
aussi en C++ pour être clean avec le compilo.
Pour cet exemple précis, je parlerais d'ailleurs plutôt de conversion, car
un "int" n'est pas un objet en Java(1)(2) (pas plus qu'en C++ d'ailleurs).
On ne peut donc pas parler de relation "est-un" (qui est modélisé par
l'héritage en programmation objet).
On a plutôt une relation "peut-etre-converti-en" dans les deux langages
avec des garde-fous pour éviter de convertir n'importe quoi
en n'importe quoi.
C++ propose d'ailleurs la conversion
static_cast<Type_cible>(expression) servant (je cite) aux
"conversions bien définies, mais non-sûres".
Comme nous sommes en plein dans ce cas, ton exemple s'écrirait proprement
int i = static_cast<int>( 0.5f ) ;
en C++, ce qui est plus précis que la version Java.

On dispose aussi de reinterpret_cast, const_cast et dynamic_cast
pour préciser explicitement ses intentions lors d'un conversion.

Donc, cher contradicteur, je me permet de nuancer vos affirmations.

(1) Ceci montre d'ailleurs que la réclame
"Java est 100% objet" n'engage que ceux qui la croient.
(2) J'irai plus loin : un String n'est pas un objet non plus, c'est un
être hybride qui a certaines propriétés des objets et des types natifs.
------

arithmétique des pointeurs ca veut bien dire : si p1, p2 sont des pointeurs alors p1+p2 aussi, p1-p2, p1+1, etc... et donc permettent d'accéder à la mémoire un peu n'importe comment. En java, évidemment, ca n'a aucun sens. l'accès à la mémoire se fait par conteneur (avec get/set). D'ou un accroissement de la sécurité. De plus on peut convertir un tableau de type primitif en son équivalent DirectBuffer (et inversement) dans l'ordre natif des octets de la machine, de manière transparente.

Oui, etc.. Sauf que :
1) p1+p2 n'a pas de sens physique (somme de 2 adresses) et ne compile
même pas.
2) p1-p2 a un sens mais n'est pas un pointeur, c'est un entier
(nombre d'éléments entre les deux adresses)
3) seul, p1+1 est bien un pointeur.
Dans ces conditions on comprend pourquoi la mémoire est accédée n'importe
comment.

Je prédis un "brillant" avenir à ce paquetage. Il est en contradiction
avec la philosophie de Java.

est-ce donc que tu reconnais que la philosophie de java est bonne est que le c++ n'a pas de brillant avenir? .Bon évidement c'est pas aussi simple. De plus, les buffer à accès direct ne sont qu'un cas particulier de ce package. Les entrès-sorties étaient le point faible de java. Le package nio permet de réaliser enfin des applications très performantes, capable de monter en charge. Le package io permet de gérer simplement la mémoire avec des performances qui sont bien connues (à cause du blocage avec les threads entre autres)...Le package nio, un peu plus complexe permet de gérer précisement les buffers sans blocage. Les domaines de prédilection de ce package, d'après les cas d'utilisation que l'on peut trouver dans les entreprises, sont les serveurs, le chargement des données en mémoire, etc...
Quant à la sécurité, je ne sais pas si elle est toujours garantie par rapport aux tiers, chose importante quand on travaille dans une architecture distribuée.

Bonne dans l'absolu ne signifie pas grand chose (bonne pour quoi ?)
je veux simplement dire que

- c'est une porte ouverte à la bidouille
- sa présence témoigne de la volonté de combler des faiblesses.

Je pense que Sun devrait s'abstenir de ce genre de chose
qui ne peut que les décrédibiliser, mais je n'ai
pas étudié le package d'assez près pour être catégorique.
Je constate que, toi aussi, tu as un doute sur la sécurité de la chose.
------

En fait le code d'un template n'est compilé que si on réalise une instance de ce template. C'est un peu le point faible car tant qu'aucune instanciation n'est faite, il n'y a aucun moyen de vérifier le type (à chaque techno son inconvénient bien sur).

Evidemment, puisque les types sont fixés à l'instanciation !
De toute façon, un code générique non instancié ne risque pas
plus de générer un erreur d'exécution qu'un programme pas encore écrit.

pour ceux qui s'intéressent aux templates en java, il existe des projets en cours. http://igm.univ-mlv.fr/~forax/java/jlx/template/paper/Je crois que Sun, si ce n'est pas déjà fait, devrait s'inspirer de ces travaux de recherche qui sont très prometteurs.

Et bien voila, on y vient! Je me souviens d'une argumentation de pro-Java
il y a quelques années qui proclamait haut et fort que les templates ne servaient
à rien en java puisqu'on pouvait fourrer n'importe quel objet dans un conteneur.

Ceci montre que la véritable puissance d'un langage est avant tout d'être extensible.

A bon tu connais bcp de langage qui ne sont pas extensibles?
Tu vois qu'il n'y a pas que les performances dans la vie.

Plein !!!! (dont un dont le nom commence par J et finit par a).
Un langage extensible est un langage dans lequel ce que tu développes ne peut
pas être distingué de ce qui existait avant.
Un exemple frappant est FORTH : tu peux tout redéfinir (même les structures de contrôle
en étant habile), et tout ce que tu as développé s'utilise comme du natif. LISP est un
autre exemple, mais ces deux langages ont en commun une syntaxe extrêmement frustre,
et d'autres caractéristiques ce qui en limitent l'usage.

En ce qui concerne C++, les types que tu peux définir s'utilisent exactement
comme les types natifs (même syntaxe, même façon de les passer en paramètres,
interface pouvant être basée sur des opérateurs, etc.)
Leurs performances sont également très proches (tu vois que les perf, dans la vie,
ça sert, même si il n'y a pas que ça -effectivement-)
C++ permet également de définir des opérateurs de conversion, etc.
Tout ceci fait que les types que tu définis sont absolument indiscernables des types
natifs.
L'extensibilité c'est ça, et Java ne le fait pas.

L'extensibilité, c'est aussi de pouvoir implémenter facilement des
fonctionalités qui nécessiteraient autrement une modification des structure
de contrôle du langage.
Par exemple, C++ utilise un concept tout simple, mais très utile : le destructeur.
Regardes de près Jthreads++ et tu verra qu'il est utilisé pour implémenter les
sections critiques (synchronized en Java).
Voila un concept qui a été écarté dans la conception de Java, et qui pourtant
remplace a lui seul synchronized, finalize() et finally.
Pas mal pour un truc qui ne sert a rien.
(Voir dans les post antérieurs mes interventions à ce sujet).
L'extensibilité, c'est ça et Java ne le permet pas.

L'extensibilité, c'est aussi que les extensions n'épuisent pas le programmeur
qui les utilise et la machine qui les exécute.
Lorque je vois les sinistres bidouilles qu'il faut faire pour
donner à un "int" une très vague sémantique objet, je pleure :
conversion en int->Integer, puis Integer->int pour la moindre opération,
puis retour en Integer, et vlan, la JVM pédale à chaque conversion !
L'extensibilité, c'est ça et Java ne l'offre pas.

En plus sans java, JThread n'existerait pas, on peut donc reconnaitre que java propose de bonne idées en programmation.

J'espère que tu ne veux pas dire que les concepteurs de Java ont inventé les threads ?
Il s'agit de mise en oeuvre d'un concept qui existaient et avait été implémenté bien avant.
Le nom Jthreads++ est un nom "commercial" qui rappelle que les fontionnalités sont identiques
et c'est tout. J'ai fait pendant longtemps des threads en C (pas C++) : c'était beaucoup moins
commode qu'en Java, mais ça marchait. Il se trouve qu'en C++, c'est aussi commode et qu'il
n'y a pas eu besoin pour cela de modifier le langage.

J'affirme qu'en moyenne, on peut s'attendre à obtenir 80 à 100% des performances du c++ optimisé. Maintenant dans l'application que je développe, je ne vais pas m'amuser à la faire en c++ pour le plaisir de faire du benchmark, je m'en fous.

Ben .. d'accord, mettons que je m'en fiche aussi,
mais d'ou sortent les 80 à 100% si tu n'as pas essayé ?
De toute façon le problème réel est ci-dessous.

Il est notoire que les calculs 3D coûtent cher et doivent
donc représenter une part importantes des temps d'exécution.
Je me demande donc si vous n'avez pas mesuré les performance d'open GL
(qui ne doit pas être écrit en Java, et peut d'ailleurs largement reposer
sur le matériel) au lieu de celle de votre code.
Avez vous profilé l'appli pour voir ou se passe le temps d'exécution ?

Evidemment la librairie opengl pour java est réalisée avec jni. Lors de l'exécution, le JIT optimise les accès comme si ils étaient en natif. Donc les appels de méthodes opengl se font à la même vitesse qu'en c++. Maintenant la perte de performance se fait dans la gestion de la mémoire, d'ou les optimisation que je donne. De plus, il est possible d'améliorer le système de chargement des textures avec nio.
Quant au profilage, ma foi, il est évident que le goulot d'étranglement est ici la capacité de la carte graphique. TOUS les calculs sont effectués par opengl, donc en natif.
Si je veux distribuer mon appli, il faut que je fournisse une dll pour windows, une librairie pour linux, pour beos, etc.. qui sont fournies

Le librairie open GL est *appelée* au travers de JNI (interface avec du code natif)
elle n'est pas réalisée *avec* JNI; c'est plus qu'une nuance, ça n'a rien à voir.
Ce que je supposais se vérifie donc, ton appli exécute du code natif (en
proportion inconnue).

Le temps que tu as mesuré ne concerne donc pas du code Java mais du code C ou C++
encapsulé par une surchouche Java. En fait, c'est même peut-être plus compliqué
si des opérations sont faites par hardware.
Je trouve assez fort, et carrément non scientifique de prétendre mesurer la rapidité
d'un langage de cette manière (c-a-d en exécutant du code écrit dans un autre langage)

Par exemple: (et ce n'est qu'un exemple car je ne connais pas les chiffres réels)

Supposons que dans une appli C++ utilisant OpenGL, 90% du temps soit consommé
par openGL et 10% ailleurs (ça me semble être une hypothèse minimale puisque
tu dis que TOUS les calculs sont faits par openGL.)

Sur 100s on passe donc
90s en OpenGL 10s ailleurs.
Recodons la partie non openGL en Java et *supposons* que celle ci soit 5 fois plus lente
on obtient donc
90s en OpenGL 50s ailleurs, soit 140s c-a-d seulement 1,4 fois le temps initial
ce qui est en contradiction avec notre hypothèse de départ (5 fois).
Ce type de test ne mesure donc absolument pas les perf du langage.

On va me rétorquer qu'on en a rien à faire puisque, de toute façon on récupère bien 80à90%
des perf du C++ pur. Manque de pot, on à perdu au passage tout ce qui fait l'intérêt de Java
a) la simplicité puisqu'on est obligé de se prendre la tête avec des optimisations,
des accès direct à je ne sais quoi, des transformations de tables Java en tables natives, etc.
b) le programme n'a plus l'universalité que devrait fournir la JVM, puisque tu dois fournir
les bibli openGL (DLL ou .so) pour qu'il tourne. Il se trouve exactement dans la même
situation que n'importe quel programme compilé, en C++ ou autre, ce qui fait s'effondrer
tout le modèle java.

Vrai ou faux ?


Je crois qu'il ne faut pas avancer comme cela des chiffres qui, si ils
ne sont pas faux en eux mêmes, ne représentent pas ce qu'ils sont censés
représenter. Je pense sincérement qu'ils ont été pris pour argent comptant
et contribuent à alimenter la rumeur.