Vincent wrote: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...
:-)
J'attend juste de savoir ce qui est faux dans ce que j'ai dit... Je suis
curieux.
Vincent wrote:
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...
:-)
J'attend juste de savoir ce qui est faux dans ce que j'ai dit... Je suis
curieux.
Vincent wrote: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...
:-)
J'attend juste de savoir ce qui est faux dans ce que j'ai dit... Je suis
curieux.
(Vincent) wrote in message news:...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++.
Oui, c'est également ce que dit l'article : la variance est très
grande et le critère fondamental n'est pas le langage utilisé mais le
programmeur.
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.
Je voulais faire principalement deux choses (en ce moment), en dehors
de progresser en programmation (ce qui, par expérience, ne se fait
qu'en programmant)
Et en lisant (beaucoup), crois-moi tu ne trouveras jamais aussi vite
: un administrateur d'IA pour un jeu, et des
algorithmes d'optimisation (toutes les méthodes utilisées en
math.app., du data minig AG-réseaux de neurones jusqu'à des méthodes
systématiques de recherche opérationnelle). Pour clarifier la première
partie, l'idée est de créer un programme qui reçoit le code de
sous-classes de la classe abstraite IA, et qui les fait jouer les unes
contre les autres pour les comparer. Bien sûr, de pair à ce projet, il
y a la programmation d'une de ces IA.
A priori tu n'auras pas besoin de portabilité, très peu besoin des API
vclassine@elan.fr (Vincent) wrote in message news:<9e49e584.0307280504.515584ab@posting.google.com>...
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++.
Oui, c'est également ce que dit l'article : la variance est très
grande et le critère fondamental n'est pas le langage utilisé mais le
programmeur.
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.
Je voulais faire principalement deux choses (en ce moment), en dehors
de progresser en programmation (ce qui, par expérience, ne se fait
qu'en programmant)
Et en lisant (beaucoup), crois-moi tu ne trouveras jamais aussi vite
: un administrateur d'IA pour un jeu, et des
algorithmes d'optimisation (toutes les méthodes utilisées en
math.app., du data minig AG-réseaux de neurones jusqu'à des méthodes
systématiques de recherche opérationnelle). Pour clarifier la première
partie, l'idée est de créer un programme qui reçoit le code de
sous-classes de la classe abstraite IA, et qui les fait jouer les unes
contre les autres pour les comparer. Bien sûr, de pair à ce projet, il
y a la programmation d'une de ces IA.
A priori tu n'auras pas besoin de portabilité, très peu besoin des API
(Vincent) wrote in message news:...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++.
Oui, c'est également ce que dit l'article : la variance est très
grande et le critère fondamental n'est pas le langage utilisé mais le
programmeur.
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.
Je voulais faire principalement deux choses (en ce moment), en dehors
de progresser en programmation (ce qui, par expérience, ne se fait
qu'en programmant)
Et en lisant (beaucoup), crois-moi tu ne trouveras jamais aussi vite
: un administrateur d'IA pour un jeu, et des
algorithmes d'optimisation (toutes les méthodes utilisées en
math.app., du data minig AG-réseaux de neurones jusqu'à des méthodes
systématiques de recherche opérationnelle). Pour clarifier la première
partie, l'idée est de créer un programme qui reçoit le code de
sous-classes de la classe abstraite IA, et qui les fait jouer les unes
contre les autres pour les comparer. Bien sûr, de pair à ce projet, il
y a la programmation d'une de ces IA.
A priori tu n'auras pas besoin de portabilité, très peu besoin des API
wrote in message news:...Surtout, si j'écris en C++ :
Objet o1 ;
Objet o2 = o1 ;
(Il y a aussi le fait que o1 est garanti d'être un objet valide. Pas de
pointeur null possible.)
Est-ce que ça veut dire que si la classe Objet est munie de la méthode
dyn. f(), alors o1.f() a toujours un sens ?
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.
Est-ce qu'on peut dire que définir une classe abstraite avec quelques
méthodes abstraites et quelques champs et demader aux programmeurs
d'écrire des sous-classes de cette classe abstraite, c'est de la
programmation par contrat ?
Non c'est juste de l'héritage.
Conclusion : il va falloir que je lise le livre conseillé ci-dessus
(de Meyer).
Et oui, et c'est plus une encyclopédie qu'une nouvelle...
kanze@gabi-soft.fr wrote in message news:<d6652001.0307280246.3f53879d@posting.google.com>...
Surtout, si j'écris en C++ :
Objet o1 ;
Objet o2 = o1 ;
(Il y a aussi le fait que o1 est garanti d'être un objet valide. Pas de
pointeur null possible.)
Est-ce que ça veut dire que si la classe Objet est munie de la méthode
dyn. f(), alors o1.f() a toujours un sens ?
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.
Est-ce qu'on peut dire que définir une classe abstraite avec quelques
méthodes abstraites et quelques champs et demader aux programmeurs
d'écrire des sous-classes de cette classe abstraite, c'est de la
programmation par contrat ?
Non c'est juste de l'héritage.
Conclusion : il va falloir que je lise le livre conseillé ci-dessus
(de Meyer).
Et oui, et c'est plus une encyclopédie qu'une nouvelle...
wrote in message news:...Surtout, si j'écris en C++ :
Objet o1 ;
Objet o2 = o1 ;
(Il y a aussi le fait que o1 est garanti d'être un objet valide. Pas de
pointeur null possible.)
Est-ce que ça veut dire que si la classe Objet est munie de la méthode
dyn. f(), alors o1.f() a toujours un sens ?
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.
Est-ce qu'on peut dire que définir une classe abstraite avec quelques
méthodes abstraites et quelques champs et demader aux programmeurs
d'écrire des sous-classes de cette classe abstraite, c'est de la
programmation par contrat ?
Non c'est juste de l'héritage.
Conclusion : il va falloir que je lise le livre conseillé ci-dessus
(de Meyer).
Et oui, et c'est plus une encyclopédie qu'une nouvelle...
(Endymion) wrote in message
news:...wrote in message
news:...Ç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.
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.
(Endymion) wrote in message
news:...wrote in message
news:...Ç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.
wrote in message
news:...(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.
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.
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.
wrote in message
news:...(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.
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.
Et comment u fais en Java pour faire une classe qui "implémenteé deux
interfaces au snes donné par James (c'est-à-dire avec pre-conditions et
post-conditions) ? Sans héritage multiple d'implémentation, je ne vois pas
comment on pourrait s'en sortir.
Je comprend ce que tu veux dire, mais en fait en java la question se
pose différemment. Tu ne peux pas hérité de deux classe, donc pas de
deux classe "avec contrat". Quand tu hérites d'une classe tu as tous
les outils pour éviter la rupture du contrat. Si tu veux récupèrer
l'interface et le comportement de deux classes, tu dois:
- implémenter les deux interfaces. Ou une seule si tu hérites de
l'autre. Ou implémenter une interface qui hériterait des deux
autres...
- composer les deux classes portant le comportement, ou une seule
si tu hérit de l'autre, éventuellement en les dérivant.
- "brancher" les interfaces avec les classes membres.
Et comment u fais en Java pour faire une classe qui "implémenteé deux
interfaces au snes donné par James (c'est-à-dire avec pre-conditions et
post-conditions) ? Sans héritage multiple d'implémentation, je ne vois pas
comment on pourrait s'en sortir.
Je comprend ce que tu veux dire, mais en fait en java la question se
pose différemment. Tu ne peux pas hérité de deux classe, donc pas de
deux classe "avec contrat". Quand tu hérites d'une classe tu as tous
les outils pour éviter la rupture du contrat. Si tu veux récupèrer
l'interface et le comportement de deux classes, tu dois:
- implémenter les deux interfaces. Ou une seule si tu hérites de
l'autre. Ou implémenter une interface qui hériterait des deux
autres...
- composer les deux classes portant le comportement, ou une seule
si tu hérit de l'autre, éventuellement en les dérivant.
- "brancher" les interfaces avec les classes membres.
Et comment u fais en Java pour faire une classe qui "implémenteé deux
interfaces au snes donné par James (c'est-à-dire avec pre-conditions et
post-conditions) ? Sans héritage multiple d'implémentation, je ne vois pas
comment on pourrait s'en sortir.
Je comprend ce que tu veux dire, mais en fait en java la question se
pose différemment. Tu ne peux pas hérité de deux classe, donc pas de
deux classe "avec contrat". Quand tu hérites d'une classe tu as tous
les outils pour éviter la rupture du contrat. Si tu veux récupèrer
l'interface et le comportement de deux classes, tu dois:
- implémenter les deux interfaces. Ou une seule si tu hérites de
l'autre. Ou implémenter une interface qui hériterait des deux
autres...
- composer les deux classes portant le comportement, ou une seule
si tu hérit de l'autre, éventuellement en les dérivant.
- "brancher" les interfaces avec les classes membres.
(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) ?
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...
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...
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...
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...
(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) ?
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...
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...
La vitesse qui compte la plus, en général, c'est la vitesse de
développement.
Ce n'est pas dit. Si tu fais attention à ne travailler qu'avec les
double[], le résultat pourrait être même plus vite qu'avec C++. Sur
certaines plateformes, en tout cas -- la portabilité à ce niveau, ce
n'est pas le fort de Java.
La vitesse qui compte la plus, en général, c'est la vitesse de
développement.
Ce n'est pas dit. Si tu fais attention à ne travailler qu'avec les
double[], le résultat pourrait être même plus vite qu'avec C++. Sur
certaines plateformes, en tout cas -- la portabilité à ce niveau, ce
n'est pas le fort de Java.
La vitesse qui compte la plus, en général, c'est la vitesse de
développement.
Ce n'est pas dit. Si tu fais attention à ne travailler qu'avec les
double[], le résultat pourrait être même plus vite qu'avec C++. Sur
certaines plateformes, en tout cas -- la portabilité à ce niveau, ce
n'est pas le fort de Java.
