Java et C++

Dany

25/07/2003 à 09:12

Bon, leur différence réside dans leurs qualités et défauts.
Tout d'abord Java c'est portable, c'est à dire qu'avec les fichier compiler
tu peut les faire tourner sur tout les OS. L'inconvénient c'est que du coup
tu n'a pas d'executable (enfin il y a bien des moyen de faire des exe mais
selon le cas la place que prend l'executable est dérisoire). Un autre
inconvénient de Java, c'est tout ce qui est graphique. Si tu fait une
application qui tourne autour du graphisme tu vas avoir du mal (il n'y a pas
tellement de blibliotheque graphique). Il faut savoir qu'un systeme de
déploiment de platforme à travers internet existe pour Java, c'est trés
impressionant il faut le voir sur le site de sun.
Pour le C++ l'avantage (enfin personnellement) c'est que totu le monde
l'utilise, du coup si tu as un probleme tu trouvera bien quelqu'un qui à
déjà eu ce probleme. Il y a des milliard de bibliotheque, si tu travail
uniquement sous windows, ben tu à les MFC (trés pratique dans le
développement graphique ^_^). Par contre c'est pas portable, inconvénient
qui ne me fait ni chaud ni froid puisque je travail exlusivement sous
Windows.

Voila j'ai pas fait une liste exaustive, je ne t'ai surement pas parlé des
différences techniques, mais c'est comme ça que je le voi.

Ciao
Dany

Martinez Jerome

25/07/2003 à 11:49

Dany wrote:

Voila j'ai pas fait une liste exaustive, je ne t'ai surement pas parlé des
différences techniques, mais c'est comme ça que je le voi.

tu oublies un truc important : Java, ca rame, ca rame, ca n'arrette pas
de ramer...
Java gere un garbage collector, souvent buggé dès que tu veux faire de
la gestion memoire poussée (ton appli se met a consomer 100 Mo alors que
tu a aloué puis supprimé 10 Mo 10 fois, hum... et hop, d'un coup ton
appli freeze le temps de purger, et tu ne peux rien y faire...)
Java, dès que tu sors des componsants classique a afficher (pour
dessiner par exemple), suivant le JDK installé (meme des versions
differentes d'une meme boite), ben ca s'affiche compeletement
differement, une horreur. On est loin d'un wxWindows ou Qt...
Bref Java sert pour faire du code a afficher par page web (intranet,
internet), mais a eviter si on peut prendre autre chose (pas forcement c++)

Sinon, en utilisant les bonnes lib (wxWindows perso, ou Borland Kilix
pour les flemmard), une interface graphique avec de la programmation C++
est tout aussi portable, au prix d'une compilation par plateforme.

Bref :
- developpement Web --> Java
- developpement d'un logiciel --> Pas java : Perl, python, C, C++ etc...

kanze

25/07/2003 à 15:05

(Endymion) wrote in message
news:...

Vu d'un néophyte (pas débutant, mais pas très bon), quelles
différences y a-t-il entre Java et C++, mis à part quelques petites
particularités syntaxiques (syntaxe de création d'un tableau,
l'utilisation de destructeur d'objet, l'initialisation par défaut des
champs) ? Est-ce que l'héritage multiple change vraiment quelque chose
?

Ça dépend de ce qu'on veut faire. Si on a un style de programmation
résoluement OO, ils se ressemblent pour certaines choses. Sinon : C++
permet d'autres idiomes aussi, ce qui n'est pas le cas de Java.

La manque de l'héritage multiple gène parfois, mais dans l'ensemble,
c'est une différence mineur -- en C++, je l'utilise, mais pas dans
chaque hièrarchie non plus. Du point de vue de l'utilisateur, je vois
surtout les différences suivantes :

- En C++, on définit beaucoup de types avec une sémantique de valeur :
quand on déclare une variable de type T, c'est réelement de la place
d'un T qui est alloué par le compilateur ; il n'y a pas d'histoire
de faire des new. Pour les classes à sémantique de valeur (comme une
chaîne de caractères, des complexes, etc.), c'est beaucoup plus
simple (mais pas forcement trivial non plus) à faire correctement en
C++.

En Java, il faut déclarer la classe final, et s'assurer qu'aucune
fonction n'en modifie l'état (comme c'est le cas dans
java.lang.String). L'orientation de Java, c'est de privileger les
objets d'entité de l'application.

C'est probablement LA différence fondamentale. Elle est pervasive.
Même quand on utilise un style très OO, il s'avère qu'environ la
moitié des classes représentent des valeurs.

- Bien moins important (sauf quand tu en as besoin) : C++ a du
surcharge des opérateurs, qui permet à émuler un type de base. C'est
un épée à double tranchant -- c'est incroyablement facile à en
abuser (et comme en Java, la bibliothèque standard n'est pas
toujours un bon modèle). Mais supposons que pour des raisons
juridiques, tu sois obligé à tenir des valeurs monétaires en décimal
(c'est généralement le cas), est-ce mieux d'avoir à écrire :
total = prixHorsTax + prixHorsTax * tva ;
comme en C++, ou :
total = prixHorsTax.add( prixHorsTax.mult( tva ) ) ;
comme en Java.

- En C++, on utilise des destructeurs pour faire le menage. En Java,
les bloc de finally. La différence est, encore une fois,
fondamental. En C++, c'est la classe qui gère la ressource ou la
cohérence qui impose l'execution du nettoyage ; en Java, c'est
l'utilisateur de cette classe qui doit le faire explicitement -- et
je n'ai jamais vu un programme Java où il n'en manquait pas de bloc
de finally.

- En C++, on distingue en général entre les erreurs à traiter
localement (indiquer par des valeurs de retour d'une fonction), les
erreurs à traiter globalement (les exceptions), et les erreurs qui
ne doivent en aucun cas se produire, et où il faut avorter (les
échecs d'assertion). Java traite tout par des exceptions, ce qui le
rend extrèmement difficile, sinon impossible, à écrire un programme
qui est réelement correct -- pour pouvoir se comporter d'une façon
correcte lors d'une exception, il faut qu'il y a certaines
opérations qui ne peuvent pas lever une exception. Or, en Java, même
des chose comme une erreur dans la machine virtuelle donne lieu à
une exception.

- Java, au moins dans ces premières versions, n'avait pas de
génériques. Ce qui limiter des prédicats sur le type que pouvait
enforcer le compilateur : en C++, si tu déclare un std::vector, tu
dis au compilateur le type que tu veux y mettre, et le compilateur
l'enforce. En Java, tu écris un commentaire qui dit le type qu'il
doit contenir, et en cas d'erreur, tu as une exception à
l'execution.

- Java pose des problèmes pour la programmation par contrat. En C++,
c'est plutôt l'exception d'avoir une fonction virtuelle publique --
la plupart en sont privée. En Java, on ne peut pas déclarer une
fonction privée virtuelle. Du coup, c'est extrèmement difficile à
forcer que tous les appels de la fonction passent par une fonction
non-virtuelle (final, en Java) dans la classe de base ; fonction qui
vérifie que le contrat est maintenu.

- C++ permet la separation de l'implémentation et de l'interface. En
C++, c'est permis de définir des fonctions dans la définition de la
classe, comme on fait en Java, mais on constate très vite que c'est
une mauvaise idée. En Java, on n'a pas le choix. (Le moyen
qu'utilise C++ pour faire cette separation, l'inclusion textuelle,
est probablement le pire qu

- Java, au moins dans les implémentations que je connais, impose un
certain dynamisme, qui n'est pas toujours souhaitable. En C++, si tu
veux, tu peux découper ton programme en objets dynamiques (DLL's
sous Windows, objets partagés sous Unix, mais dans les deux cas, ce
qui fait la différence, c'est que l'édition de liens se fait lors de
l'execution.) Or, globalement, un objet dynamique n'est qu'une chose
de plus que tu ne contrôles pas complètement lors de l'execution. On
les évite autant que possible, à cause des erreurs qui en
proviennent.

En faveur de Java, évidemment, ce sont des bibliothèques standard pour à
peu près tout, et dans certains cas, comme les JSP, l'environement
applicatif.

Où puis-je trouver un document clair (français ou anglais) qui me
permette de faire la transition (j'ai lu un article disant que C/C++
était plus rapide que Java et nécessitait moins de lignes) ?

Ça dépend de ce que tu fais. Il y a aussi des benchmark qui tournent
plus vite en Java qu'en C++. Dans la plupart des applications, en
revanche, j'imagine que le fait que C++ ait des véritables valeurs,
qu'on peut allouer sur la pile, ou mettre directement dans une
collection, fait que le C++ serait plus rapide. Plus important, pour des
applications d'une certaine taille, je trouve qu'on les développe plus
rapidement en C++.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

pr.nm@laposte.net (Endymion) wrote in message
news:<4219ae8a.0307242127.6e18880c@posting.google.com>...

Vu d'un néophyte (pas débutant, mais pas très bon), quelles
différences y a-t-il entre Java et C++, mis à part quelques petites
particularités syntaxiques (syntaxe de création d'un tableau,
l'utilisation de destructeur d'objet, l'initialisation par défaut des
champs) ? Est-ce que l'héritage multiple change vraiment quelque chose
?

Ça dépend de ce qu'on veut faire. Si on a un style de programmation
résoluement OO, ils se ressemblent pour certaines choses. Sinon : C++
permet d'autres idiomes aussi, ce qui n'est pas le cas de Java.

La manque de l'héritage multiple gène parfois, mais dans l'ensemble,
c'est une différence mineur -- en C++, je l'utilise, mais pas dans
chaque hièrarchie non plus. Du point de vue de l'utilisateur, je vois
surtout les différences suivantes :

- En C++, on définit beaucoup de types avec une sémantique de valeur :
quand on déclare une variable de type T, c'est réelement de la place
d'un T qui est alloué par le compilateur ; il n'y a pas d'histoire
de faire des new. Pour les classes à sémantique de valeur (comme une
chaîne de caractères, des complexes, etc.), c'est beaucoup plus
simple (mais pas forcement trivial non plus) à faire correctement en
C++.

En Java, il faut déclarer la classe final, et s'assurer qu'aucune
fonction n'en modifie l'état (comme c'est le cas dans
java.lang.String). L'orientation de Java, c'est de privileger les
objets d'entité de l'application.

C'est probablement LA différence fondamentale. Elle est pervasive.
Même quand on utilise un style très OO, il s'avère qu'environ la
moitié des classes représentent des valeurs.

- Bien moins important (sauf quand tu en as besoin) : C++ a du
surcharge des opérateurs, qui permet à émuler un type de base. C'est
un épée à double tranchant -- c'est incroyablement facile à en
abuser (et comme en Java, la bibliothèque standard n'est pas
toujours un bon modèle). Mais supposons que pour des raisons
juridiques, tu sois obligé à tenir des valeurs monétaires en décimal
(c'est généralement le cas), est-ce mieux d'avoir à écrire :
total = prixHorsTax + prixHorsTax * tva ;
comme en C++, ou :
total = prixHorsTax.add( prixHorsTax.mult( tva ) ) ;
comme en Java.

- En C++, on utilise des destructeurs pour faire le menage. En Java,
les bloc de finally. La différence est, encore une fois,
fondamental. En C++, c'est la classe qui gère la ressource ou la
cohérence qui impose l'execution du nettoyage ; en Java, c'est
l'utilisateur de cette classe qui doit le faire explicitement -- et
je n'ai jamais vu un programme Java où il n'en manquait pas de bloc
de finally.

- En C++, on distingue en général entre les erreurs à traiter
localement (indiquer par des valeurs de retour d'une fonction), les
erreurs à traiter globalement (les exceptions), et les erreurs qui
ne doivent en aucun cas se produire, et où il faut avorter (les
échecs d'assertion). Java traite tout par des exceptions, ce qui le
rend extrèmement difficile, sinon impossible, à écrire un programme
qui est réelement correct -- pour pouvoir se comporter d'une façon
correcte lors d'une exception, il faut qu'il y a certaines
opérations qui ne peuvent pas lever une exception. Or, en Java, même
des chose comme une erreur dans la machine virtuelle donne lieu à
une exception.

- Java, au moins dans ces premières versions, n'avait pas de
génériques. Ce qui limiter des prédicats sur le type que pouvait
enforcer le compilateur : en C++, si tu déclare un std::vector, tu
dis au compilateur le type que tu veux y mettre, et le compilateur
l'enforce. En Java, tu écris un commentaire qui dit le type qu'il
doit contenir, et en cas d'erreur, tu as une exception à
l'execution.

- Java pose des problèmes pour la programmation par contrat. En C++,
c'est plutôt l'exception d'avoir une fonction virtuelle publique --
la plupart en sont privée. En Java, on ne peut pas déclarer une
fonction privée virtuelle. Du coup, c'est extrèmement difficile à
forcer que tous les appels de la fonction passent par une fonction
non-virtuelle (final, en Java) dans la classe de base ; fonction qui
vérifie que le contrat est maintenu.

- C++ permet la separation de l'implémentation et de l'interface. En
C++, c'est permis de définir des fonctions dans la définition de la
classe, comme on fait en Java, mais on constate très vite que c'est
une mauvaise idée. En Java, on n'a pas le choix. (Le moyen
qu'utilise C++ pour faire cette separation, l'inclusion textuelle,
est probablement le pire qu

- Java, au moins dans les implémentations que je connais, impose un
certain dynamisme, qui n'est pas toujours souhaitable. En C++, si tu
veux, tu peux découper ton programme en objets dynamiques (DLL's
sous Windows, objets partagés sous Unix, mais dans les deux cas, ce
qui fait la différence, c'est que l'édition de liens se fait lors de
l'execution.) Or, globalement, un objet dynamique n'est qu'une chose
de plus que tu ne contrôles pas complètement lors de l'execution. On
les évite autant que possible, à cause des erreurs qui en
proviennent.

En faveur de Java, évidemment, ce sont des bibliothèques standard pour à
peu près tout, et dans certains cas, comme les JSP, l'environement
applicatif.

Où puis-je trouver un document clair (français ou anglais) qui me
permette de faire la transition (j'ai lu un article disant que C/C++
était plus rapide que Java et nécessitait moins de lignes) ?

Ça dépend de ce que tu fais. Il y a aussi des benchmark qui tournent
plus vite en Java qu'en C++. Dans la plupart des applications, en
revanche, j'imagine que le fait que C++ ait des véritables valeurs,
qu'on peut allouer sur la pile, ou mettre directement dans une
collection, fait que le C++ serait plus rapide. Plus important, pour des
applications d'une certaine taille, je trouve qu'on les développe plus
rapidement en C++.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Vous avez filtré cet utilisateur ! Consultez son message

(Endymion) wrote in message
news:...

Vu d'un néophyte (pas débutant, mais pas très bon), quelles
différences y a-t-il entre Java et C++, mis à part quelques petites
particularités syntaxiques (syntaxe de création d'un tableau,
l'utilisation de destructeur d'objet, l'initialisation par défaut des
champs) ? Est-ce que l'héritage multiple change vraiment quelque chose
?

Ça dépend de ce qu'on veut faire. Si on a un style de programmation
résoluement OO, ils se ressemblent pour certaines choses. Sinon : C++
permet d'autres idiomes aussi, ce qui n'est pas le cas de Java.

La manque de l'héritage multiple gène parfois, mais dans l'ensemble,
c'est une différence mineur -- en C++, je l'utilise, mais pas dans
chaque hièrarchie non plus. Du point de vue de l'utilisateur, je vois
surtout les différences suivantes :

- En C++, on définit beaucoup de types avec une sémantique de valeur :
quand on déclare une variable de type T, c'est réelement de la place
d'un T qui est alloué par le compilateur ; il n'y a pas d'histoire
de faire des new. Pour les classes à sémantique de valeur (comme une
chaîne de caractères, des complexes, etc.), c'est beaucoup plus
simple (mais pas forcement trivial non plus) à faire correctement en
C++.

En Java, il faut déclarer la classe final, et s'assurer qu'aucune
fonction n'en modifie l'état (comme c'est le cas dans
java.lang.String). L'orientation de Java, c'est de privileger les
objets d'entité de l'application.

C'est probablement LA différence fondamentale. Elle est pervasive.
Même quand on utilise un style très OO, il s'avère qu'environ la
moitié des classes représentent des valeurs.

- Bien moins important (sauf quand tu en as besoin) : C++ a du
surcharge des opérateurs, qui permet à émuler un type de base. C'est
un épée à double tranchant -- c'est incroyablement facile à en
abuser (et comme en Java, la bibliothèque standard n'est pas
toujours un bon modèle). Mais supposons que pour des raisons
juridiques, tu sois obligé à tenir des valeurs monétaires en décimal
(c'est généralement le cas), est-ce mieux d'avoir à écrire :
total = prixHorsTax + prixHorsTax * tva ;
comme en C++, ou :
total = prixHorsTax.add( prixHorsTax.mult( tva ) ) ;
comme en Java.

- En C++, on utilise des destructeurs pour faire le menage. En Java,
les bloc de finally. La différence est, encore une fois,
fondamental. En C++, c'est la classe qui gère la ressource ou la
cohérence qui impose l'execution du nettoyage ; en Java, c'est
l'utilisateur de cette classe qui doit le faire explicitement -- et
je n'ai jamais vu un programme Java où il n'en manquait pas de bloc
de finally.

- En C++, on distingue en général entre les erreurs à traiter
localement (indiquer par des valeurs de retour d'une fonction), les
erreurs à traiter globalement (les exceptions), et les erreurs qui
ne doivent en aucun cas se produire, et où il faut avorter (les
échecs d'assertion). Java traite tout par des exceptions, ce qui le
rend extrèmement difficile, sinon impossible, à écrire un programme
qui est réelement correct -- pour pouvoir se comporter d'une façon
correcte lors d'une exception, il faut qu'il y a certaines
opérations qui ne peuvent pas lever une exception. Or, en Java, même
des chose comme une erreur dans la machine virtuelle donne lieu à
une exception.

- Java, au moins dans ces premières versions, n'avait pas de
génériques. Ce qui limiter des prédicats sur le type que pouvait
enforcer le compilateur : en C++, si tu déclare un std::vector, tu
dis au compilateur le type que tu veux y mettre, et le compilateur
l'enforce. En Java, tu écris un commentaire qui dit le type qu'il
doit contenir, et en cas d'erreur, tu as une exception à
l'execution.

- Java pose des problèmes pour la programmation par contrat. En C++,
c'est plutôt l'exception d'avoir une fonction virtuelle publique --
la plupart en sont privée. En Java, on ne peut pas déclarer une
fonction privée virtuelle. Du coup, c'est extrèmement difficile à
forcer que tous les appels de la fonction passent par une fonction
non-virtuelle (final, en Java) dans la classe de base ; fonction qui
vérifie que le contrat est maintenu.

- C++ permet la separation de l'implémentation et de l'interface. En
C++, c'est permis de définir des fonctions dans la définition de la
classe, comme on fait en Java, mais on constate très vite que c'est
une mauvaise idée. En Java, on n'a pas le choix. (Le moyen
qu'utilise C++ pour faire cette separation, l'inclusion textuelle,
est probablement le pire qu

- Java, au moins dans les implémentations que je connais, impose un
certain dynamisme, qui n'est pas toujours souhaitable. En C++, si tu
veux, tu peux découper ton programme en objets dynamiques (DLL's
sous Windows, objets partagés sous Unix, mais dans les deux cas, ce
qui fait la différence, c'est que l'édition de liens se fait lors de
l'execution.) Or, globalement, un objet dynamique n'est qu'une chose
de plus que tu ne contrôles pas complètement lors de l'execution. On
les évite autant que possible, à cause des erreurs qui en
proviennent.

En faveur de Java, évidemment, ce sont des bibliothèques standard pour à
peu près tout, et dans certains cas, comme les JSP, l'environement
applicatif.

Où puis-je trouver un document clair (français ou anglais) qui me
permette de faire la transition (j'ai lu un article disant que C/C++
était plus rapide que Java et nécessitait moins de lignes) ?

Ça dépend de ce que tu fais. Il y a aussi des benchmark qui tournent
plus vite en Java qu'en C++. Dans la plupart des applications, en
revanche, j'imagine que le fait que C++ ait des véritables valeurs,
qu'on peut allouer sur la pile, ou mettre directement dans une
collection, fait que le C++ serait plus rapide. Plus important, pour des
applications d'une certaine taille, je trouve qu'on les développe plus
rapidement en C++.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

kanze

25/07/2003 à 15:24

"Dany" wrote in message
news:<bfql54$vkb$...

Bon, leur différence réside dans leurs qualités et défauts.

Tout d'abord Java c'est portable, c'est à dire qu'avec les fichier
compiler tu peut les faire tourner sur tout les OS.

Ça n'a pas été mon expérience. Au contraire, du fait que ce que tu
livres dépend d'une machine virtuelle et des bibliothèques sur la
machine client fait que ton programme peut s'arrêter de marcher d'un
jour à l'autre, sans que rien n'y ait changé.

L'inconvénient c'est que du coup tu n'a pas d'executable (enfin il y a
bien des moyen de faire des exe mais selon le cas la place que prend
l'executable est dérisoire).

Je n'ai pas trop compris. Est-ce que tu fais référence aux problèmes dus
au dynamisme forcé et l'édition de liens à l'execution, ou à quelque
chose d'autre.

Un autre inconvénient de Java, c'est tout ce qui est graphique.

Il n'y aurait pas une faute de frappe, ou quelque chose. Tout ce qui est
graphique, c'est un des avantages de Java, parce que lui, au moins, a
une bibliothèque standard qui s'adresse au problème.

Si tu fait une application qui tourne autour du graphisme tu vas avoir
du mal (il n'y a pas tellement de blibliotheque graphique).

Il n'y a rien de tout de graphique en C++. En Java, Swing n'est pas des
plus rapides, et il bouffe pas mal de mémoire, mais il est facile à
utiliser.

Il faut savoir qu'un systeme de déploiment de platforme à travers
internet existe pour Java, c'est trés impressionant il faut le voir
sur le site de sun.

C'est vrai, si tu en as besoin. Et encore -- nous déployons nos
logiciels client (écrit en C++) à travers le reseau aussi. Mais il a
fallu plus de travail pour y arriver, et ça ne marche vraiment que parce
que toutes les machines client sont des PCs. (Et parce que certains
logiciels ne fonctionnent que sur les PC, tout ceux qui travaille sous
Unix sont obligé à avoir deux machines sur leur bureau.)

Ce n'est pas vraiment une différence des langages, mais plutôt des
implémentations, mais il faut dire que les implémentations Java ont
prèsque toutes un modèle de déploiement différent que celui du C++.

Pour le C++ l'avantage (enfin personnellement) c'est que tout le monde
l'utilise, du coup si tu as un probleme tu trouvera bien quelqu'un qui
à déjà eu ce probleme.

Là, je crois qu'il n'y a pas grande différence entre C++ et Java.

Il y a des milliard de bibliotheque,

De qualité et de portabilité très variable. Moi, je ne peux même pas
utiliser Boost ici, parce qu'un des compilateurs ne l'avale pas.

si tu travail uniquement sous windows,

Tu te limites beaucoup.

ben tu à les MFC (trés pratique dans le développement
graphique ^_^).

Du peu que j'ai pu voir, c'est loin de valoir Swing. Mais j'avoue que je
ne m'en suis jamais servi dans une application. (À une exception près,
mes projets ont été soit grand serveur, soit application industrielle.
Alors, du coup, pas de Windows. L'exception, c'était bien un charpente
graphique pour des clients sous Windows, mais c'était en Java.)

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

"Dany" <dany_tambicannou@yahoo.fr> wrote in message
news:<bfql54$vkb$1@news-reader4.wanadoo.fr>...

Bon, leur différence réside dans leurs qualités et défauts.

Tout d'abord Java c'est portable, c'est à dire qu'avec les fichier
compiler tu peut les faire tourner sur tout les OS.

Ça n'a pas été mon expérience. Au contraire, du fait que ce que tu
livres dépend d'une machine virtuelle et des bibliothèques sur la
machine client fait que ton programme peut s'arrêter de marcher d'un
jour à l'autre, sans que rien n'y ait changé.

L'inconvénient c'est que du coup tu n'a pas d'executable (enfin il y a
bien des moyen de faire des exe mais selon le cas la place que prend
l'executable est dérisoire).

Je n'ai pas trop compris. Est-ce que tu fais référence aux problèmes dus
au dynamisme forcé et l'édition de liens à l'execution, ou à quelque
chose d'autre.

Un autre inconvénient de Java, c'est tout ce qui est graphique.

Il n'y aurait pas une faute de frappe, ou quelque chose. Tout ce qui est
graphique, c'est un des avantages de Java, parce que lui, au moins, a
une bibliothèque standard qui s'adresse au problème.

Si tu fait une application qui tourne autour du graphisme tu vas avoir
du mal (il n'y a pas tellement de blibliotheque graphique).

Il n'y a rien de tout de graphique en C++. En Java, Swing n'est pas des
plus rapides, et il bouffe pas mal de mémoire, mais il est facile à
utiliser.

Il faut savoir qu'un systeme de déploiment de platforme à travers
internet existe pour Java, c'est trés impressionant il faut le voir
sur le site de sun.

C'est vrai, si tu en as besoin. Et encore -- nous déployons nos
logiciels client (écrit en C++) à travers le reseau aussi. Mais il a
fallu plus de travail pour y arriver, et ça ne marche vraiment que parce
que toutes les machines client sont des PCs. (Et parce que certains
logiciels ne fonctionnent que sur les PC, tout ceux qui travaille sous
Unix sont obligé à avoir deux machines sur leur bureau.)

Ce n'est pas vraiment une différence des langages, mais plutôt des
implémentations, mais il faut dire que les implémentations Java ont
prèsque toutes un modèle de déploiement différent que celui du C++.

Pour le C++ l'avantage (enfin personnellement) c'est que tout le monde
l'utilise, du coup si tu as un probleme tu trouvera bien quelqu'un qui
à déjà eu ce probleme.

Là, je crois qu'il n'y a pas grande différence entre C++ et Java.

Il y a des milliard de bibliotheque,

De qualité et de portabilité très variable. Moi, je ne peux même pas
utiliser Boost ici, parce qu'un des compilateurs ne l'avale pas.

si tu travail uniquement sous windows,

Tu te limites beaucoup.

ben tu à les MFC (trés pratique dans le développement
graphique ^_^).

Du peu que j'ai pu voir, c'est loin de valoir Swing. Mais j'avoue que je
ne m'en suis jamais servi dans une application. (À une exception près,
mes projets ont été soit grand serveur, soit application industrielle.
Alors, du coup, pas de Windows. L'exception, c'était bien un charpente
graphique pour des clients sous Windows, mais c'était en Java.)

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Vous avez filtré cet utilisateur ! Consultez son message

"Dany" wrote in message
news:<bfql54$vkb$...

Bon, leur différence réside dans leurs qualités et défauts.

Tout d'abord Java c'est portable, c'est à dire qu'avec les fichier
compiler tu peut les faire tourner sur tout les OS.

Ça n'a pas été mon expérience. Au contraire, du fait que ce que tu
livres dépend d'une machine virtuelle et des bibliothèques sur la
machine client fait que ton programme peut s'arrêter de marcher d'un
jour à l'autre, sans que rien n'y ait changé.

L'inconvénient c'est que du coup tu n'a pas d'executable (enfin il y a
bien des moyen de faire des exe mais selon le cas la place que prend
l'executable est dérisoire).

Je n'ai pas trop compris. Est-ce que tu fais référence aux problèmes dus
au dynamisme forcé et l'édition de liens à l'execution, ou à quelque
chose d'autre.

Un autre inconvénient de Java, c'est tout ce qui est graphique.

Il n'y aurait pas une faute de frappe, ou quelque chose. Tout ce qui est
graphique, c'est un des avantages de Java, parce que lui, au moins, a
une bibliothèque standard qui s'adresse au problème.

Si tu fait une application qui tourne autour du graphisme tu vas avoir
du mal (il n'y a pas tellement de blibliotheque graphique).

Il n'y a rien de tout de graphique en C++. En Java, Swing n'est pas des
plus rapides, et il bouffe pas mal de mémoire, mais il est facile à
utiliser.

Il faut savoir qu'un systeme de déploiment de platforme à travers
internet existe pour Java, c'est trés impressionant il faut le voir
sur le site de sun.

C'est vrai, si tu en as besoin. Et encore -- nous déployons nos
logiciels client (écrit en C++) à travers le reseau aussi. Mais il a
fallu plus de travail pour y arriver, et ça ne marche vraiment que parce
que toutes les machines client sont des PCs. (Et parce que certains
logiciels ne fonctionnent que sur les PC, tout ceux qui travaille sous
Unix sont obligé à avoir deux machines sur leur bureau.)

Ce n'est pas vraiment une différence des langages, mais plutôt des
implémentations, mais il faut dire que les implémentations Java ont
prèsque toutes un modèle de déploiement différent que celui du C++.

Pour le C++ l'avantage (enfin personnellement) c'est que tout le monde
l'utilise, du coup si tu as un probleme tu trouvera bien quelqu'un qui
à déjà eu ce probleme.

Là, je crois qu'il n'y a pas grande différence entre C++ et Java.

Il y a des milliard de bibliotheque,

De qualité et de portabilité très variable. Moi, je ne peux même pas
utiliser Boost ici, parce qu'un des compilateurs ne l'avale pas.

si tu travail uniquement sous windows,

Tu te limites beaucoup.

ben tu à les MFC (trés pratique dans le développement
graphique ^_^).

Du peu que j'ai pu voir, c'est loin de valoir Swing. Mais j'avoue que je
ne m'en suis jamais servi dans une application. (À une exception près,
mes projets ont été soit grand serveur, soit application industrielle.
Alors, du coup, pas de Windows. L'exception, c'était bien un charpente
graphique pour des clients sous Windows, mais c'était en Java.)

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

kanze

25/07/2003 à 15:37

Martinez Jerome wrote in
message news:<bfqueh$...

Dany wrote:
Voila j'ai pas fait une liste exaustive, je ne t'ai surement pas
parlé des différences techniques, mais c'est comme ça que je le voi.

tu oublies un truc important : Java, ca rame, ca rame, ca n'arrette
pas de ramer...

Ça dépend de ce que tu fais, et j'ai vu (et j'ai pu réproduire) des
benchmark où Java était plus vite que C++.

Java gere un garbage collector, souvent buggé dès que tu veux faire de
la gestion memoire poussée (ton appli se met a consomer 100 Mo alors
que tu a aloué puis supprimé 10 Mo 10 fois, hum...

Je n'ai pas eu de problèmes à cause des bogues dans la ramasse-miettes.
Il faut dire, en revanche, qu'il faut savoir s'en servir : avec le Java
de Sun, il prend un beau bout de mémoire à l'initialisation, où il fait
joujou. Si c'est un problème, parce que tu n'as pas besoin d'autant de
mémoire, il y a des options à l'invocation qui permet à changer le
montant.

Sinon, avec des ramasse-miettes, comme avec beaucoup d'autres choses, il
faut trouver l'équilibre -- plus la mémoire disponible est grosses,
moins on essaie un rammassage, et plus le programme tourne vite. On dit
souvent qu'il faut un peu près deux fois plus de mémoire avec un
ramasse-miettes que sans, pour avoir une performance équivalente. Mais
tout dépend de l'application.

et hop, d'un coup ton appli freeze le temps de purger, et tu ne peux
rien y faire...)

Là non plus, je n'ai jamais vu ça.

Java, dès que tu sors des componsants classique a afficher (pour
dessiner par exemple), suivant le JDK installé (meme des versions
differentes d'une meme boite), ben ca s'affiche compeletement
differement, une horreur.

C'est effectivement un problème, lié au modèle de deploiement.

En revanche, essaie de faire tourner ton programme C++ avec MFC sur un
Sparc sous Solaris. Il n'y a pas que du mauvais dans le modèle Java --
tout dépend de l'application.

On est loin d'un wxWindows ou Qt...

Mais combien d'applications C++ utilise wxWindows ou Qt ? Vue qu'ils ne
sont pas standard.

Bref Java sert pour faire du code a afficher par page web (intranet,
internet), mais a eviter si on peut prendre autre chose (pas forcement
c++)

Je serais prèsque d'accord, mais pour d'autres raisons.

Sinon, en utilisant les bonnes lib (wxWindows perso, ou Borland Kilix
pour les flemmard), une interface graphique avec de la programmation
C++ est tout aussi portable, au prix d'une compilation par plateforme.

Au prix d'une compilation par plateforme, et beaucoup de peines à
l'écriture, le C++ peut être plus portable. Parce que, justement, c'est
compilé et linké ; avec Java, même si ça a marché, tu ne sais jamais si
ça va marcher chez le client, parce qu'il a une autre version de la JVM,
ou une autre version des bibliothèques, ou...

Bref :
- developpement Web --> Java
- developpement d'un logiciel --> Pas java : Perl, python, C, C++ etc...

Je ne serais pas si catégorique. J'ai bien aimé Java/Swing pour les GUI,
par exemple. Et il y a des développement Web où C++ convient plus que
Java. Mais en général, tu as raison à dire qu'il ne faut pas se limiter
à un seul langage, et qu'il faut utiliser celui qui convient pour
l'application à faire.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Martinez Jerome <jerome.martinez@aenlever-orangefrance.com> wrote in
message news:<bfqueh$15f1@news.rd.francetelecom.fr>...

Dany wrote:

Voila j'ai pas fait une liste exaustive, je ne t'ai surement pas
parlé des différences techniques, mais c'est comme ça que je le voi.

tu oublies un truc important : Java, ca rame, ca rame, ca n'arrette
pas de ramer...

Ça dépend de ce que tu fais, et j'ai vu (et j'ai pu réproduire) des
benchmark où Java était plus vite que C++.

Java gere un garbage collector, souvent buggé dès que tu veux faire de
la gestion memoire poussée (ton appli se met a consomer 100 Mo alors
que tu a aloué puis supprimé 10 Mo 10 fois, hum...

Je n'ai pas eu de problèmes à cause des bogues dans la ramasse-miettes.
Il faut dire, en revanche, qu'il faut savoir s'en servir : avec le Java
de Sun, il prend un beau bout de mémoire à l'initialisation, où il fait
joujou. Si c'est un problème, parce que tu n'as pas besoin d'autant de
mémoire, il y a des options à l'invocation qui permet à changer le
montant.

Sinon, avec des ramasse-miettes, comme avec beaucoup d'autres choses, il
faut trouver l'équilibre -- plus la mémoire disponible est grosses,
moins on essaie un rammassage, et plus le programme tourne vite. On dit
souvent qu'il faut un peu près deux fois plus de mémoire avec un
ramasse-miettes que sans, pour avoir une performance équivalente. Mais
tout dépend de l'application.

et hop, d'un coup ton appli freeze le temps de purger, et tu ne peux
rien y faire...)

Là non plus, je n'ai jamais vu ça.

Java, dès que tu sors des componsants classique a afficher (pour
dessiner par exemple), suivant le JDK installé (meme des versions
differentes d'une meme boite), ben ca s'affiche compeletement
differement, une horreur.

C'est effectivement un problème, lié au modèle de deploiement.

En revanche, essaie de faire tourner ton programme C++ avec MFC sur un
Sparc sous Solaris. Il n'y a pas que du mauvais dans le modèle Java --
tout dépend de l'application.

On est loin d'un wxWindows ou Qt...

Mais combien d'applications C++ utilise wxWindows ou Qt ? Vue qu'ils ne
sont pas standard.

Bref Java sert pour faire du code a afficher par page web (intranet,
internet), mais a eviter si on peut prendre autre chose (pas forcement
c++)

Je serais prèsque d'accord, mais pour d'autres raisons.

Sinon, en utilisant les bonnes lib (wxWindows perso, ou Borland Kilix
pour les flemmard), une interface graphique avec de la programmation
C++ est tout aussi portable, au prix d'une compilation par plateforme.

Au prix d'une compilation par plateforme, et beaucoup de peines à
l'écriture, le C++ peut être plus portable. Parce que, justement, c'est
compilé et linké ; avec Java, même si ça a marché, tu ne sais jamais si
ça va marcher chez le client, parce qu'il a une autre version de la JVM,
ou une autre version des bibliothèques, ou...

Bref :
- developpement Web --> Java
- developpement d'un logiciel --> Pas java : Perl, python, C, C++ etc...

Je ne serais pas si catégorique. J'ai bien aimé Java/Swing pour les GUI,
par exemple. Et il y a des développement Web où C++ convient plus que
Java. Mais en général, tu as raison à dire qu'il ne faut pas se limiter
à un seul langage, et qu'il faut utiliser celui qui convient pour
l'application à faire.

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Vous avez filtré cet utilisateur ! Consultez son message

Martinez Jerome wrote in
message news:<bfqueh$...

Dany wrote:
Voila j'ai pas fait une liste exaustive, je ne t'ai surement pas
parlé des différences techniques, mais c'est comme ça que je le voi.

tu oublies un truc important : Java, ca rame, ca rame, ca n'arrette
pas de ramer...

Ça dépend de ce que tu fais, et j'ai vu (et j'ai pu réproduire) des
benchmark où Java était plus vite que C++.

Java gere un garbage collector, souvent buggé dès que tu veux faire de
la gestion memoire poussée (ton appli se met a consomer 100 Mo alors
que tu a aloué puis supprimé 10 Mo 10 fois, hum...

Je n'ai pas eu de problèmes à cause des bogues dans la ramasse-miettes.
Il faut dire, en revanche, qu'il faut savoir s'en servir : avec le Java
de Sun, il prend un beau bout de mémoire à l'initialisation, où il fait
joujou. Si c'est un problème, parce que tu n'as pas besoin d'autant de
mémoire, il y a des options à l'invocation qui permet à changer le
montant.

Sinon, avec des ramasse-miettes, comme avec beaucoup d'autres choses, il
faut trouver l'équilibre -- plus la mémoire disponible est grosses,
moins on essaie un rammassage, et plus le programme tourne vite. On dit
souvent qu'il faut un peu près deux fois plus de mémoire avec un
ramasse-miettes que sans, pour avoir une performance équivalente. Mais
tout dépend de l'application.

et hop, d'un coup ton appli freeze le temps de purger, et tu ne peux
rien y faire...)

Là non plus, je n'ai jamais vu ça.

Java, dès que tu sors des componsants classique a afficher (pour
dessiner par exemple), suivant le JDK installé (meme des versions
differentes d'une meme boite), ben ca s'affiche compeletement
differement, une horreur.

C'est effectivement un problème, lié au modèle de deploiement.

En revanche, essaie de faire tourner ton programme C++ avec MFC sur un
Sparc sous Solaris. Il n'y a pas que du mauvais dans le modèle Java --
tout dépend de l'application.

On est loin d'un wxWindows ou Qt...

Mais combien d'applications C++ utilise wxWindows ou Qt ? Vue qu'ils ne
sont pas standard.

Bref Java sert pour faire du code a afficher par page web (intranet,
internet), mais a eviter si on peut prendre autre chose (pas forcement
c++)

Je serais prèsque d'accord, mais pour d'autres raisons.

Sinon, en utilisant les bonnes lib (wxWindows perso, ou Borland Kilix
pour les flemmard), une interface graphique avec de la programmation
C++ est tout aussi portable, au prix d'une compilation par plateforme.

Au prix d'une compilation par plateforme, et beaucoup de peines à
l'écriture, le C++ peut être plus portable. Parce que, justement, c'est
compilé et linké ; avec Java, même si ça a marché, tu ne sais jamais si
ça va marcher chez le client, parce qu'il a une autre version de la JVM,
ou une autre version des bibliothèques, ou...

Bref :
- developpement Web --> Java
- developpement d'un logiciel --> Pas java : Perl, python, C, C++ etc...

Je ne serais pas si catégorique. J'ai bien aimé Java/Swing pour les GUI,
par exemple. Et il y a des développement Web où C++ convient plus que
Java. Mais en général, tu as raison à dire qu'il ne faut pas se limiter
à un seul langage, et qu'il faut utiliser celui qui convient pour
l'application à faire.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Dany

25/07/2003 à 15:37

Houla effectivement j'ai fait quelques erreurs.

Ça n'a pas été mon expérience. Au contraire, du fait que ce que tu
livres dépend d'une machine virtuelle et des bibliothèques sur la
machine client fait que ton programme peut s'arrêter de marcher d'un
jour à l'autre, sans que rien n'y ait changé.

Ben, je n'ai jamais eu ce genre de probleme, je livre toujours une platforme
de déploiment.

L'inconvénient c'est que du coup tu n'a pas d'executable (enfin il y a
bien des moyen de faire des exe mais selon le cas la place que prend
l'executable est dérisoire).

Je n'ai pas trop compris. Est-ce que tu fais référence aux problèmes dus
au dynamisme forcé et l'édition de liens à l'execution, ou à quelque
chose d'autre.

Non en fait je fait référence à la création d'exécutable "natif" (pas trés
natif d'ailleur)

Un autre inconvénient de Java, c'est tout ce qui est graphique.

Il n'y aurait pas une faute de frappe, ou quelque chose. Tout ce qui est
graphique, c'est un des avantages de Java, parce que lui, au moins, a
une bibliothèque standard qui s'adresse au problème.

La je ne suis trompé je voulais dire "java c'est tout sauf graphique". Les
bibliotheque graphiques de java ont encore du retard par rapport à ceux de
c++ (trop pour moi)

Martinez Jerome

25/07/2003 à 17:46

wrote:

Mais combien d'applications C++ utilise wxWindows ou Qt ? Vue qu'ils ne
sont pas standard.

Malheuresement, C++ n'a jamais voulu s'attacher a une autre interface
que std::cin et std::cout

C'est très très dommage.
Mais le paliatif tel que WxWindows n'est pas déplaisant, certe ce n'est
pas standart si on est difficile sur les mots, mais on peut dire que
c'est un standart de fait au vu du nombre de plate-formes supportées et
de son age :)

Gabriel Dos Reis

25/07/2003 à 18:25

Martinez Jerome writes:

| wrote:
|
| > Mais combien d'applications C++ utilise wxWindows ou Qt ? Vue qu'ils ne
| > sont pas standard.
|
| Malheuresement, C++ n'a jamais voulu s'attacher a une autre interface
| que std::cin et std::cout

Comment ? Pourrais-tu développer ?

-- Gaby

Fabien LE LEZ

26/07/2003 à 07:46

On Fri, 25 Jul 2003 17:46:15 +0200, Martinez Jerome
wrote:

Malheuresement, C++ n'a jamais voulu s'attacher a une autre interface
que std::cin et std::cout

C++ est un langage fait pour être portable -- i.e. tout élément du
standard doit avoir un sens sur toutes les machines où un compilateur
C++ existe ou peut exister. En particulier, puisque parler de souris
sur une chaîne hi-fi ou d'écran VGA sur un four à micro-ondes n'a pas
de sens, le standard ISO-C++ ne parle pas de ces notions.

Il est bien sûr possible de définir un standard pour une interface
graphique à la Windows/X/MacOS, mais ce n'est plus du ressort du
C++...

--
Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/
et http://www.aminautes.org/forums/serveurs/tablefr.html
Archives : http://groups.google.com/advanced_group_search
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html

Fabien LE LEZ

26/07/2003 à 07:49

On 25 Jul 2003 06:24:12 -0700, wrote:

ben tu à les MFC (trés pratique dans le développement
graphique ^_^).

Du peu que j'ai pu voir, c'est loin de valoir Swing.

Faut dire que les MFC sont assez vieilles, pas forcément conçues par
des gens qui connaissaient bien le C++, et de toutes façons obsolètes
(plein de gens continuent à les utiliser, mais ça m'étonnerait que
Microsoft investisse encore dans le développement des MFC...)

--
Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/
et http://www.aminautes.org/forums/serveurs/tablefr.html
Archives : http://groups.google.com/advanced_group_search
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html

Java et C++

10 réponses

Veuillez sélectionner un problème