Java et C++

Le seul langage à ma connaissance qui
offre un support complet pour la programmation par contrats est Eiffel,

et si tu veux en savoir plus à ce sujet je t'invite à lire Bertrand
Meyer - "Object-Oriented Software Construction" (évidemment, les
exemples sont en Eiffel).
Au delà de la programmation par contrat c'est un excellent bouquin sur

la conception/programmation OO, tout le monde devrait le lire, en
particulier les débutants en OO.

Julien Blanc <Julien.Blanc@imag.fr> wrote in message
news:<3f24c4ea$0$1798$626a54ce@news.free.fr>...

Endymion wrote:

kanze@gabi-soft.fr wrote in message
news:<d6652001.0307250505.2aa2a95@posting.google.com>...

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

"Il n'y a pas d'histoire de new" : tu veux dire qu'on ne peut pas
caster un champ pour qu'il change de type ? ou que la création d'un
objet ne s'écrie pas par Objet o = new Objet(); ?

non, ça s'écrit simplement Objet o; (comme tu déclares un int ou un
float). Et tu peux bien sûr écrire Objet *o=new Objet(); pour avoir un
objet avec identité.

Surtout, si j'écris en C++ :

Objet o1 ;
Objet o2 = o1 ;

j'ai deux objets distincts ; une modification de o2 ne modifie pas o1.
Tandis qu'en Java, après la deuxième ligne, j'ai toujours un seul objet,
et si j'appelle une fonction qui modifie o2, o1 se trouve modifié aussi.
(Il y a aussi le fait que o1 est garanti d'être un objet valide. Pas de
pointeur null possible.)

Et comme tu dis, quand on veut l'identité en C++, on peut l'avoir, au
moyen des pointeurs.

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

Je ne compremd pas l'importance de la différenciation : si tu mets
dans ton exception un catch{System.exit(0);}, le programme quitte
s'il rencontre cette erreur.

Si j'ai bien retenu ce qui a été dit lors de ma dernière discussion
avec James sur ce sujet, il ressort qu'il est parfois pire de lever
une exception (qui exécutera un certain nombre de destructeurs et
d'opérations sur la pile, pouvant créer des dégats importants) que
d'arrêter tout brutalement. Et en l'occurrence, comme tu ne sais pas
vraiment quand est-ce que ta machine virtuelle peut avoir une erreur
(ça peut dépendre de beaucoup de choses, y compris un problème
matériel), il est très imprudent de lever une exception qui peut
provoquer des dégats importants plutôt que de faire un arrêt brutal,
beaucoup moins dangereux.

Tout à fait. Le problème est peut-être moins aigu en Java, parce qu'il
n'y a pas de destructeurs, mais si le programme est bien écrit, il y
aurait bien un catch ici et là pour faire un peu de menage. Et si l'état
interne de ton programme n'est pas cohérent, il se peut qu'en essayant
de faire du menage, tu fais plus de mal que de bien.

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

Je suppose que la programmation par contrat consiste à créer une
classe abstraite avec des méthodes abstraites, ce qui force tous
ceux qui doivent créer des sous-classes de cette classe à définir un
certain nombre de méthodes.

Non. Ca consiste à définir dans ta classe de base toutes les
préconditions, postconditions, invariants que doit respecter ta classe
et chacune de ses méthodes (et par conséquent chacune de ses classes
dérivées).

En premier lieu, évidemment, il consiste à définir un contrat pour la
classe et pour toutes ses fonctions. Un contrat qui précise ce que doit
faire la classe/fonction, et ce que doit faire l'utilisateur/appelant.
Ensuite, on aime ajouter des tests pour valider le contrat autant que
possible.

Dans le cas d'une hièrarchie, évidemment, la classe de base définit un
contrat. Et si on tient à la règle de substitution, qui veut que toute
classe dérivée puisse remplacer la classe de base dans toutes ces
utilisations, la classe dérivée doit aussi remplir le contrat. Donc, le
code pour enforcer le contrat va dans la classe de base. Dans une
fonction non-virtuelle dans la classe de base, puisqu'on ne veut pas que
la classe dérivée puisse le modifier.

En c++, il n'y a aucun mécanisme natif pour gérer cela, mais des
styles d'écriture qui le permettent (de manière peu élégante à mon
goût, le résultat est moyen (AMHA, il y'a certaines choses que je n'ai
jamais réussi à faire, mais peut-être que ça vient plus de mon
incompétence :) )).

L'élégance n'y est pas, c'est sûr. Mais enfin, c'est du C++, il ne faut
pas trop s'attendre à l'élégance en général. Pour la reste, je trouve
que c'est plus souple que ce que fournit par exemple Eiffel. (On peut,
par exemple, y mettre aussi de l'instrumentation, et non seulement des
validations.) En revanche, d'après ce que je sais, en Eiffel, on peut
modifier le contrat dans les classes dérivées, dans la mésure que les
modifications ne mettent pas le principe de substitution en jeu
(préconditions plus laches, postconditions plus serrées) ; la solution
C++ ne le permet pas.

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

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

kanze@gabi-soft.fr wrote in message news:<d6652001.0307250505.2aa2a95@posting.google.com>...

Ç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.
Je ne sais pas ce qu'est le style OO. Du coup, je ne suis pas sûr de

connaître différents styles de programmation.

- 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.
"Il n'y a pas d'histoire de new" : tu veux dire qu'on ne peut pas

caster un champ pour qu'il change de type ? ou que la création d'un
objet ne s'écrie pas par Objet o = new Objet(); ?

En fait "physiquement" il n'éxiste que des pointeur sur Objet en java.

Concrètement en C++ tu peux écrire:
CString s;
ou
CString * ps;

En java, c'est:
String s;
Syntaxiquement ça ressemble à la première écriture, mais physiquement
ça correspond plus à la deuxième, c'est pour ça qu'en java tu fais
systèmatiquement des new sur les objet.
Par contre c'est l'inverse pour les types primitif:

C++:
int i;
int * pi;

Java:
int i;
Là la syntaxe ne trouble pas, il s'agit de l'équivalent de la première
écriture en C++, par contre pour avoir "l'équivalent" de la seconde
écriture tu doit utiliser les classe Integer, Float...

- 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.
Ma question est hors sujet (je devrais la poser sur .lang.java) mais

comme tu en parles : qu'est-ce qu'un bloc finally ? (question qui
prouve que je programme sans faire le ménage comme tu le fais
remarquer ci-dessus)
try

{
//instructions à surveiller
}
finally
{
//instructions qui seront éxécutées quoiqu'il arrive (execptions ou
pas) lors de l'éxécution de des "instructions à surveiller".
}

En fait en java le garbage collector fait une bonne partie du boulot,
même si il est de bon goût de l'aider passer un certains niveau de
programmation. En fait les blocs try-finally sont nécessaires surtout
pour désallouer ce qui ne sera pas désallouer par le garbage collector
(notamment les ressources crées par une DLL native...)

- 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.
Je ne compremd pas l'importance de la différenciation : si tu mets

dans ton exception un catch{System.exit(0);}, le programme quitte s'il
rencontre cette erreur.
C'est encore un cas de programmation auquel tu n'as pas du être

confronter, d'ailleurs ça n'est pas mon domaine favoris non plus. En
gros je pense que l'idée c'est que le comportement des exceptions est
moins prévisible que celui du signalement d'erreur par code de retour.
Par conséquent ça pose des problèmes pour s'assurer de l'ordre
d'execution du code... Mais c'est juste une intuition Kanze pourra
mieux t'éclairer que moi.

Juste une correction quand même, Java permet (dans ce domaine) la même
chose que C++. La différence c'est que l'api Java utilise plus
volontier les exceptions, mais rien n'oblige à faire de même dans son
propre code.

- 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.
Je suppose que la programmation par contrat consiste à créer une

classe abstraite avec des méthodes abstraites, ce qui force tous ceux
qui doivent créer des sous-classes de cette classe à définir un
certain nombre de méthodes.
Pas exactement l'idée c'est plutôt de s'assurer que le contrat de

chaque méthode soit respecter, par exemple qu'un argument de la
fonction n'est pas nul, ou que l'appel de telle fonction n'est
effectuée que dans une état donné de l'objet.

Mais là encore je ne suis pas tout à fait d'accord avec Kanze en fait
java permet tout à fait ce genre de chose. Pour les arguments et pour
une autre discussion sur C++ et Java (a propos de la qualité) voir le
fil "Pour ou contre un code 100% objet" sur fr.comp.objet.

- 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.
C'est une approche très industrielle de la chose. Disons que selon les

domaines d'applications cette contrainte peut ne pas être pénalisante.

Il n'y a donc pas d'équivalents Java des dlls ?
En fait en java tout ce comporte un peu comme des DLL dans la mesure

ou rien n'est vraiment "assemblé" en static. Mais je dirais que
l'équivalent des DLL (et des exe d'ailleurs) c'est les fichier JAR.

kanze@gabi-soft.fr wrote in message news:<d6652001.0307250505.2aa2a95@posting.google.com>...

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.
C'est une des différences fondamentales, mais pas forcément la plus

importante en pratique, ça dépends du domaine d'application...

- 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.
Vite dit:

total = prixHorsTaxe.applyTaxe(tva);
Est tout à fait acceptable et applyTaxe n'est guère plus long à écrire
que la surcharge de l'opérateur. Même si l'opérateur peut être employé
ailleurs...

Comme tu le dis c'est à double tranchant, et ça n'est qu'une
fonctionnalité syntaxique qui en tout état de cause n'est pas souvent
vraiment utile.

- 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.
Là encore c'est une commodité syntaxique (qui sera incluse dans la

1.5) rien n'empêche d'écrire une version de chaque conteneur par type,
c'est lourd mais ça se fait.

- 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.
Euh? Privée virtuelle = protected (sauf que protected est accessible

aussi depuis le package, mais en principe on n'authorise personne de
non fiable à écrire dans son package).

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.
public abstract class AbstractTest

{
public final void faire_truc()
{
pre_condition();
faire_vraiment_truc();
post_condition();
}
private void pre_condition();
private void post_condition();

protected abstract void faire_vraiment_truc();
}

- 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
En fait on peut très bien le faire en définissant une interface

pour chaque classe (ce qui n'est pas une mauvaise idée du reste),
c'est optionnel.

- 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.
Effectivement, mais ce gain de performance dépend de la qualité du

programmeur et n'est pas toujours nécessaire...

Plus important, pour des
applications d'une certaine taille, je trouve qu'on les développe plus
rapidement en C++.
Je n'en suis pas convaincu, mais c'est normal ce genre de chose est

éminemment subjectif.

vclassine@elan.fr (Vincent) wrote in
news:9e49e584.0307280439.5a39ef43@posting.google.com:

- 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.
Euh? Privée virtuelle = protected (sauf que protected est accessible

aussi depuis le package, mais en principe on n'authorise personne de
non fiable à écrire dans son package).

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.
public abstract class AbstractTest

{
public final void faire_truc()
{
pre_condition();
faire_vraiment_truc();
post_condition();
}
private void pre_condition();
private void post_condition();

protected abstract void faire_vraiment_truc();
}

Et la classe finale ne pourra implémenter qu'un seul contrat ... à moins
que l'on puisse dériver de plusieurs classes abstraites, mais j'ai un
gros doute.

--
Luc Hermitte <hermitte at free.fr>
FAQ de <news:fr.comp.lang.c++> :
<http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/>
Dejanews : <http://groups.google.com/advanced_group_search>

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) ?
C'est l'arbre qui cache la forêt, ces différences syntaxiques sont la

conséquence de différences de fond.

Est-ce que l'héritage multiple change vraiment quelque chose
?
D'abord en java tu peux faire de l'héritage multiple d'interfaces (une

interface peut hériter de plusieurs autres, et une classe peut
implémenter plus d'interfaces). Ce que tu ne peut pas faire c'est de
l'héritage multiple de comportement (une classe hérite de plusieurs).

A partir de là le fait que l'héritage multiple de classe soit interdit
rend pénible l'écriture de certains code, mais a aussi des avantages
de sécurité (d'ailleurs on pourrait dire qu'il en va de même pour
l'héritage simple de comportement). Mais ça ne concerne que les
programmeurs objet avancés, les autres font plus souvent des trucs
dangereux avec... Si ça t'intéresse tu peux jeter un coup d'oeil au
fil "Pour ou contre un code 100% objet" sur fr.comp.objet, il y a une
discussion autour de ce sujet...

(j'ai lu un article disant que C/C++
était plus rapide que Java
Dans l'absolu, c'est vrai.

Pour la perf il ne faut pas se leurrer la vitesse d'éxécution d'une
appli dépend d'abord de la qualité du programmeur. Et a mon avis un
bon programmeur java doit pouvoir déculotter un programmeur moyen en
C++. Mais la première question à se poser, avant même de savoir si tu
vas pouvoir aller deux fois plus vite en C++, c'est est-ce que ton
besoin premier est la vitesse d'exécution...

Si tu dois écrire une application de CAO 3D, java risque de te
bloquer. Mais si tu dois juste écrire une appli de gestion le critère
n'est clairement pas la perf, sauf si tu dois utiliser des machines
très limitées...
A mon avis c'est surtout la mémoire consommée qui est plus importante
en java. Après la vitesse d'éxécution est souvent la même, même si il
faut reconnaitre que le temps de démarrage est alongé. Bien sûr ça
dépend de ton application...

De plus rien ne t'empêche de profiter des avantages de java tout en
codant certaines parties coûteuses en C++...

et nécessitait moins de lignes) ?

Je répond pour la perf plus bas. Sur le nombre de ligne je peux déjà
te répondre que tous les programmes java et C++ peuvent s'écrirent sur
une seule ligne, ça n'est pas un critère.
Java demande un peu plus d'écriture à cause des try catch fréquents,
mais je dirais qu'un bon programmeur C++ les écrira (ou les
"if...else" qui les remplacent) partout où c'est obligatoire en Java,
donc match nul.
Java est basé sur la même syntaxe que C++ donc pas de différence
significative... ça n'est pas comme en Delphi, Pascal, Ada, VB, ... où
tu écris:
if truc then
begin
.
.
.
end;
Là clairement il y a plus d'écriture, mais certains préfèrent...



Globalement ta question est un peu vague, pour obtenir une bonne
réponse précise si tu souhaite te former à un des deux langages sans
but applicatif précis, ou si tu as une application (ou un domaine
d'application) en tête dis-nous laquelle, sans quoi tu n'auras pas de
réponse complète et pertinente à ta question.

PS: laisse tomber les posts de Dany et Jérôme Martinez, ils sont
partiellement faux (surtout ceux de Jérôme). Comme j'écris ça je vais
devoir argumenter, mais aujourd'hui j'ai la flemme alors j'attends un
peu qu'ils me hurlent dessus...
:-)
En attendant tu peux toujours comparer la portabilité de Kylix,
wxWindows et Swing (voire même SWT). Ou comparer Eclipe et Netbeans
avec VisualStudio pour te faire une idée des possiblité graphique de
(respectivement) SWT et Swing, comparé aux MFC...

Martinez Jerome <jerome.martinez@aenlever-orangefrance.com> wrote in message news:<bg2t3g$68r3@news.rd.francetelecom.fr>...

James Kanze wrote:

Sans parler de l'aspect risque. Quand j'étais à la Dresdner
Bank, ils ont décidé de réécrire toute une application en
Java, parce que la bibliothèque de fenêtrage sur laquelle elle
était basée était retirée du marché.

D'ou l'interet de l'open-source...
(Et c'est pourquoi je préfère WxWindows a Qt, trop restrictif a mon gout)
C'est bien joli l'open source, mais honnêtement peu d'entreprises

peuvent se permettre de maintenir une bibliothèque que leurs auteurs
aurait abandonné... Pour corriger un bug ça va bien, mais si tu dois
faire évoluer le truc ça se gâte. Mais bon c'est sûr qu'en Open Source
au moins on a le choix... Ce qui est mieux à mon avis c'est de
s'appuyer sur une API dont il éxiste plusieurs implémentations...

Certes, et je crois qu'un des arguments valables contre la
normalisation d'une interface graphique est (ou au moins aurait
été lors de la dernière normalisation) que la technologie
n'est pas encore stable -- que nous ne savons pas trop ce qu'il faut
normaliser. Une norme se doit d'être stable, et il ne faut pas
oublier que si Swing n'est pas trop mal, il est aussi la troisième
version de l'interface graphique de Java.
Euh? Tu crois vraiment qu'un jour on sera vraiment plus fixé

qu'aujourd'hui sur les GUI? A contrario je dirais qu'une norme ça doit
se murir et s'appuyer sur une certaine expérience (et je crois qu'on
en a assez dans les GUI's), et ensuite évoluer (en préservant au
maximum la compatibilité ascendante).

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)
Tu utilises quoi comme MFC??? Personnelement je trouve que les MFC se

rapproche plus d'AWT que de SWING ou SWT tu peux me donner un exemple
concret d'appli s'appuyant exclusivement sur les MFC et ayant bcp de
choses remarquable par rapport à SWING ou SWT???

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...
Le temps de lancer la VM (et encore ça à bien évolué) et de faire la

compil "JIT". Après ça bouffe plus de mémoire, donc plus de chance de
"swapper" et donc de ramer, c'est tout.
Pour constater les différences liées à la gestions des threads et de
la mémoire il faut pousser beaucoup plus loin...

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...)
Soit tu es Marseillais, soit tu es très malchanceux, soit tu

programmes très mal, sois ça fait bien longtemps que tu n'as pas fait
du java...

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.
Avec le look and feel portable (Metal), non. A l'exception de quelques

détails importants pour les utilisateurs de chaque OS...

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++)
Si les aspect d'un programmes s'arrêtait à la vélocité et à l'ihm ça

se saurait...
Portabilité, distributivité?

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.
Comparer la portabilité de wxWindows avec java, me semble pencher en

la faveur de java, mais c'est à peu près recevable. Comparer avec
Kylix c'est franchement une blague, le monde ne s'arrête pas à Linux
et Windows. Mais surtout java c'est portable pour tout le reste, les
GUI n'en sont qu'une partie.

Bref :
- developpement Web --> Java
simpliste.

- developpement d'un logiciel --> Pas java : Perl, python, C, C++ etc...
En tant que chef de projet tu oserais faire une appli autre qu'un truc

très bas niveau en C au lieu de Java??? A mon avis ça manque
méchamment d'objectivité ou de connaissance tout ça...