À l'avenir, il me semble fort probable qu'il y aurait du support,
au moins partiel, pour des threads et des objets dynamiques (pour la
simple raison que dans ces deux cas, une solution pûrement
bibliothèque ne suffit pas).
À l'avenir, il me semble fort probable qu'il y aurait du support,
au moins partiel, pour des threads et des objets dynamiques (pour la
simple raison que dans ces deux cas, une solution pûrement
bibliothèque ne suffit pas).
À l'avenir, il me semble fort probable qu'il y aurait du support,
au moins partiel, pour des threads et des objets dynamiques (pour la
simple raison que dans ces deux cas, une solution pûrement
bibliothèque ne suffit pas).
Ç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
- 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
- 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
- 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
- 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
- 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.
Il n'y a donc pas d'équivalents Java des dlls ?
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.
Ç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
- 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
- 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
- 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
- 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
- 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.
Il n'y a donc pas d'équivalents Java des dlls ?
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.
Ç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
- 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
- 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
- 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
- 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
- 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.
Il n'y a donc pas d'équivalents Java des dlls ?
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.
wrote in message news:...- 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 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.
- 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.
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(); ?
- 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.
- 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.
wrote in message news:...- 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 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.
- 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.
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++...
On Fri, 25 Jul 2003 17:46:15 +0200, Martinez Jerome
<jerome.martinez@aenlever-orangefrance.com> 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++...
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++...
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é.
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é.
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é.
