[Débat] C++ vs Java

[grishka]

Merci beaucoup pour cette précision VisualCBien2 ( je vais pouvoir critiquer Java encore plus )!!

attention car ca être de la critique...

Java et les autres outils associés c'est très bien.....très bien...s'il faut un compilateur C++ pour pouvoir en tirer profit..!

A titre de comparaison , c'est comme si on achetait une voiture et qu'il faudrait une autre voiture pour piéces pour pouvoir rouler avec la première !

Waaa..Tu viens de tuer tout le monde avec cette comparaison. Je vais m'empresser de récupérer gcc pour recompiler le projet J2EE de 12000 classes sur lequel je travaille...

rien ne t'empêche de réaliser un programme entièrement en java, ou en c++ et java grace JNI. En quoi cela dénature le langage java? Je rappelle que java peut est très utile pour le scripting.

un exemple d'application entièrement java, dont la complexité n'a rien à envier à StarOffice : Eclipse (www.eclipse.org).

On est libre d'utiliser l'environnement de développement de son choix....

oui c'est pas la même chose de dire que c'est pas possible en java, .NET ou delphi, nuance...

quel intérêt et quelle pertinence de développer un outil logiciel sur mesure pour une société ??

et quel est l'intérêt et la pertinence d'une telle question dans ce débat c++/java car avec les produits windows on peut faire du sur-mesure également.
Mais je vais te répondre qq même: une société va demander un outil de gestion adapté à son entreprise, spécifique à son métier. Lui procurant une valeur ajoutée supplémentaire par rapport à un logiciel du commerce. De plus la plupart des projets en java concerne la mise au point d'une appli web distribuée. Tu en connais bcp dans le commerce?
Bref une société qui demanderait un logiciel de traitement de texte facturé 100K€, qui n'arriverait pas à faire le quart de la moitié de Word avec le double de bug si possible, j'y crois pas trop...

[++gib]

[qote]
i = i+1 et i+=1 ne sont sémantiquement pas la même chose. puisque dans un cas c'est une affectation, dans l'autre une incrémentation. Ca n'a pas le même sens. Et pour allez plus loin, en java pour incrémenté, tu est obligé d'avoir affecté une valeur avant. Ce qui est + strict sémentiquement.
[/quote]
Tu compte convaincre qui avec ça ?

Code :

i=i+1L ;

et

Code :

i += 1L ;

ont exactement le même effet donc les mêmes dangers.
Le second est simplement une optimisation du premier.
Alors pourquoi Java refuse le premier et accepte le second ? Parcequ'il à été conçu par des
débutants qui n'ont pas compris que leur manière de traiter les conversions introduisait
des distortions sémantiques dans le langage.

en c++, on peut faire tout ca, pas en java :

char s;
int i = (int)&s;

float *pf;
int *pi = (int *)pf;

class A{};
A a;
void * p = &a;

const int a;
int *pa = &a //warning seulement
pa = const_cast<int *> &a //pas de warning

Et bien voici ce que je m'attendais à lire.
Tous les exemples qui tu cites utilise un cast ou un pointeur qualifié de "universel".
En c++ comme en Java, utiliser un cast indique au compilateur que le programmeur
prend le controle du typage.
Un langage peut éviter de t'assassiner par derrière, mais il ne peut
pas t'empêcher de te suicider !

Voici les façons équivalentes de te suicider en Java.

Code :

1
2
3
4
5
int i = (int)( 1./3.) ;  // résultat == 0
X x = new X() ;
Y y = new Y() ;  // Y n'hérite pas de X
x = (X) y ;

Et ne viens surtout pas me dire que tu obtiens une exception dans le dernier cas
et que tu vas la traiter. Quel traitement vas tu entreprendre gros malin ?

[grishka]

Grégory Picavet a écrit:
Le parcours d'un Vector avec Enumeration est plus rapide que celui d'un Arraylist avec Iterator (cf message précédent)

En voila la preuve :


Et bien, je suis content pour lui.
En C++ on ne se pose pas ce genre de question, mais je
te rappelle que le sujet c'était la comparaison C++ Java.
Utilise le conteneur que tu veux, mais montre moi un code STP.

bon apparemment tu n'as pas bien lu le message, je vais donc le résumé:
la classe Vector est toujours la pour garantir la compatibilité du code. Sun l'a adapté à l'interface List pour essayer de rendre cohérent le package Collection. Mais dans un nouveau programme, il vaut mieux utiliser ArrayList avec get() et non iterator pour le parcours.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
ArrayList a  = new ArrayList();

Collection c = a;

Iterator i = c.iterator();
while(i.hasNext()) {
 i.next();
}

for(int i=0;i<a.size(); ++i) {
 a.get(i);
}

dans le deuxième cas comme on a le choix, il vaut mieux utiliser get... car c'est deux foix plus rapide...(pas de polymorphisme, pas de verification de concurrence)

Iterator n'est utile que pour decoupler le type de conteneur et la manière dont on le parcoure...

[grishka]

Voici les façons équivalentes de te suicider en Java.
Code:

int i = (int)( 1./3.) ; // résultat == 0
X x = new X() ;
Y y = new Y() ; // Y n'hérite pas de X
x = (X) y ;



Et ne viens surtout pas me dire que tu obtiens une exception dans le dernier cas
et que tu vas la traiter. Quel traitement vas tu entreprendre gros malin ?

WARF WARF si t'avais compilé, gros malin tu aurais obtenu cette erreur :

test.java:18: inconvertible types
found : Test.Y
required: Test.X
x = (X) y;
^
1 error

bref pour reprendre tes propos, c'est en c++ que tu te suicides pour le coups...

ont exactement le même effet donc les mêmes dangers.

peut-être, mais ne confond pas affectation et incrémentation

les instructions assembleur générées (ou le bytecode) ne font pas intervenir les meme opérateur

//i=i+1
mov eax,i
add eax,1
mov i,eax // c'est la ou ca casse si i est de type incompatible

//i+=1
mov eax,i
inc eax

je ne m'attends pas à ce que tu comprennes de toute facon

[++gib]

Envoyé par Grégory Picavet

Code :

Tu as raison j'aurais du compiler. :-)
Voici ce que j'aurais du écrire.

Code :

1
2
3
4
5
6
    	X x = new X() ;
        Y y = new Y() ;
        Object k = x ;
        
        y = (Y)k ; // CRASH

Ca compile fort bien et c'est une situation dans laquelle on se retrouve très souvent
en Java car on y est obligé :
Chaque fois qu'on utilse un conteneur par exemple, les objets mémorisés
n'ont plus de sémantique propre : ce sont desObjects, qui est le void*
de Java.
Pour les utiliser, on doit les "down-caster" et là plus aucun filet
ou le code est juste, ou ça plante ... A l'exécution.

Les conteneur de Java ne sont pas typés, contrairement
a ceux qu'offre la STL.
Décidément, je vous trouve singulièrement contre productifs
pour Java ces temps-ci.

peut-être, mais ne confond pas affectation et incrémentation

Tu as rééellement l'art de changer de sujet au moment ou ça devient délicat
j'ai bien pris la précaution de dire "même effets"
Et l'effet, c'est que la gestion des conversions faite par Java est
trouée comme une passoire.

Pour le reste, je te remercie de ton cours, mais ayant déjà écrit un compilateur
je m'en passe sans problème.

[adiGuba]

Salut,

Désolé de me méler à la discution.

Code :

1
2
3
4
5
X x = new X() ; 
Y y = new Y() ; 
Object k = x ; 
        
y = (Y)k ; // CRASH

Il y a bien une exception qui est levé à l'exécution: ClassCastException
Si tu aurais executer ton code tu l'aurais vu...

De plus tu peux même faire un:

Code :

1
2
if (k instanceof Y)
	y = (Y)k;

Chaque fois qu'on utilse un conteneur par exemple, les objets mémorisés
n'ont plus de sémantique propre : ce sont desObjects, qui est le void*
de Java.

Le void* du C++ est bien plus dangereux que les Object de Java.
En Java, quel que soit le type dans lequel ils ont été casté, les Object gardent toutes leurs propriétées.
Je ne pense pas que ce soit le cas en C++, mais je peux me tromper cela fait longtemps que je n'ai pas fait de C++.

a++

Tout ceci n'est qu'un ramassis de querelles d'apothicaires ou d'étudiants en informatiques à peine sortis de leur scolarité.
Cela ne vole pas haut.

Démontrer qu'une exception soit générée parce que ceci cela...ou parce qu'en C++ on utilise un pointeur non initialisé c'est bien !
Que pour calculer 10000 itérations sur des listes ,Java soit plus rapide certes.
Mais qu'en est-il de la gestion d'un projet ENTIEREMENT fait en Java genre client/serveur pour une banque par exemple ou pour un client qui va facturer des prestations ??
Je n'ai jamais pris part à un tel projet alors oui ou non est-ce que cela vaut la peine ?

Waaa..Tu viens de tuer tout le monde avec cette comparaison. Je vais m'empresser de récupérer gcc pour recompiler le projet J2EE de 12000 classes sur lequel je travaille...

Personne n'a fait allusion à la remarque que j'avais faite précedemment.
Quand est-il de Java et interface utilisateur ??
Tes 12000 classes c'est bien mais y-at-il de la gestion de contrôles , de connexions , d'E/S je ne sais quoi ,la-dedans ?

[adiGuba]

Envoyé par addicted_to_MFC

Tout ceci n'est qu'un ramassis de querelles d'apothicaires ou d'étudiants en informatiques à peine sortis de leur scolarité.
Cela ne vole pas haut.

Démontrer qu'une exception soit générée parce que ceci cela...ou parce qu'en C++ on utilise un pointeur non initialisé c'est bien !

Je suis tout a fait d'accord avec toi.
Je n'ai pas voulut montrer que Java est meilleur que C++ parce qu'il gere mieux les exceptions.
J'ai seulement voulut répondre à ++gib.

Envoyé par addicted_to_MFC

Mais qu'en est-il de la gestion d'un projet ENTIEREMENT fait en Java genre client/serveur pour une banque par exemple ou pour un client qui va facturer des prestations ??
Je n'ai jamais pris part à un tel projet alors oui ou non est-ce que cela vaut la peine ?

Je ne voit pas ce qu'a a voir le langage la dedans: C'est de la gestion de projet.
Si le projet est mal géré, cela n'a rien a voir avec le langage...

Envoyé par addicted_to_MFC

Personne n'a fait allusion à la remarque que j'avais faite précedemment.
Quand est-il de Java et interface utilisateur ??

Tu as déjà eu une réponse:

Envoyé par Grégory Picavet

Citation:
Neanmoins, simplement pour l'info, est-ce que Java sait faire cela?

Bien sur, pourquoi cela ne serait possible qu'avec MFC et c++?

Ce n'est pas parceque Java est principalement utilisé en service web qu'on ne peut pas créé d'IU.
Les composants Swing te permettent de créer n'importe quel élement standard dans les IU actuelles...

Envoyé par addicted_to_MFC

Tes 12000 classes c'est bien mais y-at-il de la gestion de contrôles , de connexions , d'E/S je ne sais quoi ,la-dedans ?

Non je suis sur qu'il s'est amusé a faire plein de classe qui se contente d'afficher Hello World sur la console...
Sans rire, pourquoi ce ne serait pas possible en Java ???

Envoyé par addicted_to_MFC

Merci beaucoup pour cette précision VisualCBien2 ( je vais pouvoir critiquer Java encore plus )!!

Java et les autres outils associés c'est très bien.....très bien...s'il faut un compilateur C++ pour pouvoir en tirer profit..!

Je ne voit pas en quoi cela pose problème ?
Ils utilisent à la fois Java et C++ (je te rappelle qu'il faut egalement le JDK pour compiler )
Ils utilisent tous les outils qui sont à leurs disposition.
C'est surement vrai qu'un code C++ bien optimisé soit plus rapide qu'un code Java optimisé dans certain domaine spécifique. Mais je reste persuadé que dans bien des cas la différence est minime, et que l'utilisation d'un langage par rapport à l'autre peut me simplifier la tache...

Envoyé par addicted_to_MFC

( je vais pouvoir critiquer Java encore plus )

Envoyé par addicted_to_MFC

Cela ne vole pas haut.

Je ne te le fais pas dire...

[grishka]

Tout ceci n'est qu'un ramassis de querelles d'apothicaires ou d'étudiants en informatiques à peine sortis de leur scolarité.
Cela ne vole pas haut.

effectivement cela reste très bas niveau, il faudrait clairement exprimer dans ce débat les cas où il est intéressant de développer en c++ et les cas où il vaut mieux utiliser java. De manière objective et pas en affirmant simplement que "java c'est plus lent que le c++ pour le calcul d'aire d'un polygone sachant que tu es obligé de faire 9*10^8 allocations dynamiques sinon c'est pas objet" cf ++gib. Ce que ++gib veut nous faire avaler, c'est que c++ est un langage cohérent dix fois plus rapide que java . Oui Java est plus lent que c++ tout le monde est d'accord pour le dire, moi le premier. Java est dix foix plus lent et occupe bien trop de mémoire pour un simple test que celui de ++gib, mais ++gib s'entete à nous dire que ce n'est pas objet si tu programmes pas comme lui en java....passons. mais si c++ proposait à la base tout les services que propose la plate-forme java, vous ne croyez pas que les performances seraient dégradées? L'objectif de java ce n'est pas de concurrencer le c++ sur les performances, mais si vous comprenez un tant soi peu la logique du langage, et la facons de réfléchir en java, vous obtiendrez des performances comparables au c++. Faire du java, ce n'est pas faire du c++. 9*10^8 allocations durant le test, quand j'y repense, il faut oser....sachant qu'un point = 3*8octets, la mémoire utilisée serait de 2Go!!! comme la machine virtuelle fonctionne avec 64Mo à la base, imaginez le garbage collector perdant son temps à allouer/désallouer...bravo ++gib, ce programme est destiné à tester le garbage collecor, ha ha

La plateforme java c'est : un langage sécurisé (dont la granularité de sécurité est au niveau des méthodes), dont le code exécutable est portable sans prendre de librairie particulière pour l'OS, simple à utiliser, disposant d'un ensemble de librairies cohérentes et simples à intégrer dans un projet.

Mais qu'en est-il de la gestion d'un projet ENTIEREMENT fait en Java genre client/serveur pour une banque par exemple ou pour un client qui va facturer des prestations ??
Je n'ai jamais pris part à un tel projet alors oui ou non est-ce que cela vaut la peine ?

C'est le type de projet adapté à la plateforme java Entreprise Edition (J2EE).
Dans j2EE, tu programmes des composants serveurs appelés EJB. Ces EJB sont déployés sur un serveur d'application qui fourni un conteneur d'EJB permettant de gérer leur cycle de vie, et fournie des services techniques standardisé de manière totalement transparente et paramétrable. Tu te soucies uniquement de la logique métier lorsque tu codes un EJB.
Les services techniques sont : l'accès aux données, la gestion des transactions, la reprise après panne, un service d'annuaire performant (JNDI), un protocole totalement intéropérable RMI-IIOP (corba), etc...

Les serveurs d'applications peuvent faire parti d'un cluster permettant ainsi une haute disponibilité et une grande tolérance aux pannes. La gestion de cluster la encore très simple.

coté client, il est possible de réaliser l'application en swing (client lourd) ou avec des JSP et un moteur de servlet intégré dans le serveur d'application (client léger).

Les performances sont excellentes par contre je ne les ai jamais comparés avec IIS, COM, ASP etc... de Microsoft (si quelqu'un a travaillé sur les deux plateforme, peut-il me dire quels sont les avantages et les inconvénients svp)?

[gregy]

Tu ferais mieux d'arrêter, tu es en train de dire à tout le monde que:
Code:
POUR OBTENIR DES PERFORMANCES CORRECTES EN JAVA
-On ne doit surtout pas programmer en objet
-On doit gérer un maximum de ressources (pools, caches etc)
soi-même à la main.


Je suis assez d'accord avec ce point de vue,
mais ça semble assez contre-productif pour Java.

Ce n'est pas du tout ce que je dit... Mais effectivement je vais arrêter là car je commence en avoir assez du discuter avec un vieux disque rayé...

[iolco51]

Je développe des applications JAVA de type GUI, souvent en CLIENT/SERVEUR, et ce sont des logiciels répondant à un besoin particulier et spécifique aux clients auquel il est destiné.

Alors je ne vais pas faire de citation, ni réouvrir un grand débat, mais dire ce qu'il en est (pour ma part) :

- C++ est nécessairement plus rapide que JAVA , tout le monde le sait, c'est INUTILE DE CONFRONTER DES LIGNES DE CODE !.

- JAVA n'est pas pour autant atrocement lent, il suffit de connaitre un peu l'API pour pouvoir "accélérer" le programme de 300% sans rien changer à l'architecture, juste savoir qu'il vaut mieux utiliser un Array dans certains cas plutot qu'un Vector, ou un StringBuffer plutot qu'un String...etc.

- dire que java est 2 fois plus lent ou 10 fois ne rime à rien, les écarts de performances seront radicalement différentes selon les types d'applications réalisées.

- Seulement les appli JAVA seront certes plus lentes, mais plus rapidement développées, plus sûres (il est dur en JAVA de générer accidentellement des fuites de mémoire), plus faciles à debogguer (code plus lisible et gestion des exceptions par la JVM) et plus portables

- Des grosses applications sont programmées ENTIEREMENT en JAVA, et elles tournent tres bien (à partir des pentium 500 et 64Mo de ram, sinon il faut reconnaitre que c'est trop lent, la JVM a son prix en termes de performances):
- le framework de développement eclipse a déjà été plusieurs fois cité (Vous devriez vous y interresser, c'est un outil très puissant)
- JBuilder (pas besoin de le présenter)
- Netbeans (que j'utilise) et SUN one studio (même architecture)
- outre ces IDE, le nouveau système de sécurité sociale au Brésil est réalisé en JAVA!!!!!


- Les véritables défauts de JAVA (à mon avis) sont :
- pas de vraie généricité ( je crois sans trop m'avancer, que c'est prévu pour la version 1.5) du coup les conteneurs génériques sont en fait des conteneurs d'objets et obligent un down-casting...
- pas d'énumérations, pas très gênant mais frustrant, mais c'est également prévu pour la verson 1.5.
- pas d'héritage multiple, mais un système d'interface qui permet une grande simplification conceptuelle, mais qui à contrario est un peu limitatif... Ce n'est pas pénalisant outre mesure, les interfaces fournissant quelque chose de plus simple et de plus souple sur la gestion, d'un développement que les héritages multiples du C++.

Sa lenteur est relative, et comme il s'agit un langage destiné à être éxécuté sur une machine virtuelle, elle est inévitable, mais le débat n'est pas là... Si on recherce les performances pures on programme en C++, en C ou même en assembleur.

A noter que JAVA commence à supporter la 3D ( GL4J , JAVA3D , OPALE) de façon plus que satisfaisante (accélération matrerielle et tout).



Et moi, pourquoi j'utlise JAVA??

J'utilise JAVA pour le développement avec SWING, pourquoi? Parce que l'API JAVA est très bien conçue, qu'elle est portable (mes developpements sont destinés à la fois à windows2000 et AIX), et surtout que à développement égal programmer en JAVA me prend presque 2 fois moins de temps qu'en C++ (API standardisée, structure orienté objet du langage efficace), et surtout les tests et les debuggages me prennent encore moins de temps, ceci grâce à la gestion des exceptions de la JVM (on a beau avoir des beaux algorithmes, quelquefois une petite erreur de frappe se glisse dans une évaluation), alors qu'en C++ on pourrait passer des journées à chercher pourquoi tout plante alors qu'un petit '<=' s'est glissé à la place d'un '<' dans le trfond du code d'une petite fonction anodine peu usitée.
NB : la panoplie de widgets dans SWING est très complète, souple, et très simple à utiliser.

Conclusion :
JAVA meilleur que C++??
Certainement pas, mais à moins de développer une grosse application dans un gros projet, il permet de développer des appli plus rapidement (donc à moindre coût) et plus portables. A chacun son rôle.
Le débat JAVA/C++ n'a aucun sens.

Enfin en termes de performances, la vraie question est là: la machine virtuelle de microsoft .NET destinée aux appli .NEt permet elle d'avoir des performances supérieures à JAVA avec la JVM???
Idem pour les délais de developpment, la portabilité, la sécurité, ...etc.
Je vous invite à y confronter vos lignes de codes puisque vous aimez ça, car là, la comparaison est censée.

Je n'ai pas voulut montrer que Java est meilleur que C++ parce qu'il gere mieux les exceptions.

Je n'ai voulu viser personne en particulier ,je lis avec intérêt les interventions de chacun bien qu'il y en ait bcp
Bon c'est vrai que j'ai eu des propos à l'emporte-piéce
Si j'ai une minute j'essaierai de prendre les codes sources et vérifier les performances.
Bon amusez vous bien avec ce que vous voulez
So long

[++gib]

Envoyé par adiGuba

Salut,

Désolé de me méler à la discution.

Code :

Il y a bien une exception qui est levé à l'exécution: ClassCastException
Si tu aurais executer ton code tu l'aurais vu...

Il ne faut pas être désolé.
J'ai bien exécuté le code et j'ai vu.
(regarde donc le commentaire //CRASH)

Ce code compile, et plante à l'exécution et c'est bien ce que je lui reproche
car il serait préférable qu'il ne compile pas.

Il est donc très facile de se suicider en Java, et de la même manière qu'en C++

Ce qui est intéressant, ce sont les causes de cette situation :

Ce crash survient parceque le passage
(obligé dans certains cas très fréquents) par un
"Object" détruit la sémantique statique
(ie: à la compilation) de l'objet :

Le compilateur ne peut donc plus détecter l'erreur de type et la laisse passer.

Il est exact que la sémantique n'est pas perdue, puisque le downcasting
permet de la restaurer.
Mais il faut pour cela ne pas se tromper en le programmant :
si le type dynamique de l'objet est X et que tu transtype vers Y
c'est le crash comme le montre mon exemple.

Il se passe exactement la même chose en C++ lorsqu'on stocke l'adresse
d'un objet dérivé dans un pointeur de base et qu'on se trompe
en effectuant le downcasting pour revenir au type réel.
Mêmes remarques à propos des références.

Peut-être que ton interpretation est qu'un exception n'est pas un CRASH
mais ceci n'est vrai que si on peut traiter l'erreur. Or là, je ne vois pas quoi
faire. Ah zut, ClassCastException !! Voyons en quoi on pourrait convertir pour
que ça marche ..
C'est ingérable, les exceptions ne sont pas faites pour corriger dynamiquement
les bugs.

Là ou C++ diffère de Java dans cet exemple , c'est que grace à la généricité,
il est rarement nécessaire de recourir au transtypage : les conteneurs
sont typés statiquement et si tu cherches à insérer un Y dans un vector<X>
tu vas te faire jeter à la compilation.
En java, tu peux inserer un Y dans un Vector, il sera considéré comme un
Object. Et lorsque tu vas le récuperer, tu vas avoir un ClassCastException
si tu le transtype en X, mais c'est trop tard.

De plus tu peux même faire un:

Code :

Je sais, je sais..
On peut faire aussi ce genre de chose en C++ sur des classes polymorphes.

Code :

1
2
3
4
5
6
	Base *b = ... ;
    // ...
    Derive *d = dynamic_cast<Derive *>(b) ;
    if( d != 0 )
    	// ...

Dans ce code, d sera non NULL seulement si le type de l'objet pointé par b
est Derive (ou une de ses classes dérivée), ce qui rend le même service
que instanceof + cast de ton exemple.
On peut faire la même chose avec des références, mais dans ce cas
on obtient l'exception "cast_exception" si le transtypage n'est pas possible.

Le void* du C++ est bien plus dangereux que les Object de Java.
En Java, quel que soit le type dans lequel ils ont été casté, les Object gardent toutes leurs propriétées.
Je ne pense pas que ce soit le cas en C++, mais je peux me tromper cela fait longtemps que je n'ai pas fait de C++.

Tu as raison : void* est effectivement plus dangereux que Object :
j'ai juste voulu donner une image et elle est imparfaite, car void*
n'a aucune sémantique. J'aurais dû préciser que les objets perdaient leur
sémantique statique.
Il n'en resta pas moins vrai que Object
est utilisé comme type générique, et ça pose les problèmes que je viens
d'exposer.
On doit etre aussi conscient que void* est outil typiquement C,
qui n'a plus besoin d'être utilisé en C++.

[Clement Cunin]

Oui, Java n'a pas actuellement d'équivalent des templates du C++.
Oui, c'est regretable.
Et Oui, ce sera normalement disponibledans la version 1.5 de Java...

Personnellement, ces erreurs que tu presente comme si grave ne representent quasiment aucun impacte quand tu utilise Java dans un cadre concret. En général, tu sais ce que tu met dedans, et tu sais ce que tu lis... Et pour les etourdis, un ClassCastException avec la ligne de l'erreur leur permet de corrigé imédiatement leur boulette...

C'est ingérable, les exceptions ne sont pas faites pour corriger dynamiquement les bugs.

Tiens, on dirais que tu n'a toujours pas compris comment on utilisait les exceptions en Java.
Non, on ne corrige pas le code avec une exception.
Mais on peut en deduire qu'une section de code est potentiellement buggé et ne plus l'utilisé, mais continué l'execution du programme. Je sais que cette theorie te semble completement sur-réaliste, et je ne vais pas une nouvelle fois essayer de te l'expliquer (Si tu veux comprendre, relis mes postes precedant).

[grishka]

pour ce qui n'en peuvent plus d'attendre les classes génériques en java, voici la version beta à télécharger :

http://developer.java.sun.com/develo...ases/generics/

[Sisko]

http://www.internalmemos.com/memos/m...p?memo_id=1321

[Olivier Constans]

Bonjour,

pour ceux que l'anglais ne rebute pas, voici une etude comparative détaillée entre java et c++ dans le cadre de la programmation des jeux 3D

http://www.rolemaker.dk/articles/evaljava/

cordialement
O.Constans

pour ceux que l'anglais ne rebute pas, voici une etude comparative détaillée entre java et c++ dans le cadre de la programmation des jeux 3D

Merci pour l'exemple mais les 2 codes sources utilisent Open GL .
Qu'en est-il de Direct X ?

Personne ne dit rien ??
Vous ne savez pas lire l'anglais peut-être ??

* Instability of Native code (JNI) which can cause the entire VM to crash.
*A simple application ("hello world" type) has a total footprint of 35-40 megs
*4246106 Large virtual memory consumption of JVM
*4380663 Multiple bottlenecks in the JVM

Que fait la police ???

The Java Problem is Recognized Internally

Merci encore internal memo !
Un programme en C++ c'est peut-être aussi instable becose pointeurs mais ça prend pas 35-40 Mo en mémoire pour afficher "Hello World" !

[Olivier Constans]

Bonjour,

Merci pour l'exemple mais les 2 codes sources utilisent Open GL .
Qu'en est-il de Direct X ?

je pense que cela n'est pas vraiment l'objet du debat ici...


c'est surtout la conclusion qui est interessante et pas seulement quelques uns des points négatifs cité dans la comparaison java/c++ :

9 Conclusion
In contrary to popular belief, Java applications are in fact not much slower than C++
applications when they have been tuned for performance. A rough estimate based on the
various benchmarks would say that tweaked Java code is a little slower than C++;
typically 20-50% on the average, but this is hard to tell for certain because of the large
variations in the speed seen in the benchmarks. The slowdown is less in 3D applications,
where performance mostly depends on the performance of the 3D hardware and not on
the programming language used.
For untweaked code, Java is much slower than C++, often a factor of three or four.
This makes it vital to tweak the performance critical sections of Java code.
Java increases the overall productivity of a software project with about 30% and the
productivity of the code phase with about 65%. This is quite a significant increase.
This productivity increase makes Java a good choice for low-profile games and for
high profile games in genres that do not rely on maximum performance to ensure sales. It
is especially good for low-profile games since the cost of Java tools and libraries are
significantly lower than those for C++. For high profile games that do not need maximum
performance, the use of Java will increase productivity and thereby allow a better game
to be produced for the same money.
Because of the relatively lower performance of Java, I cannot recommend pure Java
for highly performance critical games. It is, however, still recommended that Java is used
for at least parts of the game, for instance, as a general purpose scripting language for the
control code. Java runs much more efficient than the vast majority custom scripting
languages available.
The biggest problem at the moment with using Java for game development is that
proper ports do not exist for game consoles. I consider the current ones highly risky. If
the game is to be released on consoles then the use of Java for any part of the game
cannot be recommended.
With the development of the Java Game Profile, the rapidly improving development
tools for Java, and the still improving speed of Java virtual machines, it is likely that the
viability of Java for game development will improve in the future. However, as it stands
now, Java can only be used for games that do not need to be ported to consoles and only
partially for games that rely on maximum performance to ensure sales.

Jacob Marner, B.Sc.
Department of Computer Science
University of Copenhagen, Denmark
(jacob@marner.dk)

cordialement
O.Constans

[grishka]

100% d'accord avec ce monsieur
j'obtiens les mêmes conclusions pour mon jeu écrit avec GL4Java.

Le langage java est très performant pour le scripting, mais la tache délicate est de l'interfacer correctement avec c++ à travers JNI, dans le cas où on dispose déjà du moteur en c++.
Dans un jeu 100% java, je pense que le système de scripting équilibre les performances générales par rapport à du c++ et un système de scripting standard. Bref l'idéal est d'avoir c++ et java, mais cela implique pas mal de travail.

Vampire The masquerade est un exemple de réussite dans ce domaine.