Java vs C++

Christophe Lephay

21/09/2003 à 15:10

"Alain Naigeon" a écrit dans le message de
news:3f6d7d35$0$10407$

Du point de vue de celui qui écrit le destructeur, l'évènement
"destruction

ordonnée par GC" est-il plus aléatoire - donc plus problématique - que
l'évènement "destruction suite à clic sur bouton de fermeture" ?

Quelqu'un a dit (je sais plus qui) que tu n'avais pas la garantie que le GC
supprime effectivement l'objet, ce qui fait que le destructeur n'est pas
nécessairement appelé.

Chris

James Kanze

21/09/2003 à 18:27

"Michaël Monerau" writes:

|> Arnaud Debaene wrote:
|> > Michaël Monerau wrote:
|> >> wrote:
|> >>> On ne peut pas prendre la bibliothèque standard comme un
|> >>> modèle de bonne conception:-). Mais en l'occurance... il faut
|> >>> bien que le destructeur ferme tout et libère toutes ses
|> >>> ressources. En général, y compter est une erreur de
|> >>> programmation, mais je ne vois pas ce qu'il pourrait faire
|> >>> d'autre.

|> >> Pourquoi une erreur de programmation ? Je ne saisis pas bien...
|> >> Si ce comportement est normalisé, l'exploiter ne me paraît
|> >> pas être une erreur de programmation.

|> > S'il y a une erreur d'écriture sur le disque au moment du "close"
|> > dans le destructeur du fstream, tu as deux possiblités :
|> > - le fstream ignore silencieusement l'erreur, et le programmeur n'a
|> > aucun moyen de savoir qu'il y a eu une erreur.
|> > - le destructeur du fstream lève une exception, ce qu'il ne faut
|> > jamais faire et on entre gaillardement dans le domaine du
|> > comportement indéfini.

|> Je viens de lire une partie du chapitre sur les streams du
|> Stroustrup, voilà ce que j'y trouve :

|> # début citation #
|> §21.5.2 Closing of streams (p. 639)
|> A file can be explicitly closed by calling close() on its stream :

|> [exemple de code]

|> However, this is implicitly done by the streams's destructor. So an
|> explicit call of close() is needed only if the file must be closed
|> before reaching the end of the scope in which its stream was
|> declared.
|> # fin citation #
|>
|> Donc je me pose une question... Bjarne a-t-il occulté le
|> problème de l'exception levée dans un destructeur (qui, je le
|> rappelle au cas où, est interdit car sinon, on ne peut pas
|> remonter la pile d'appel) et les points que tu écris ci-dessus ?
|> Ou alors, à quoi pensait-il en contrepartie ?

Je ne sais pas. Je sais qu'en C, c'était très mauvause forme
d'appeler fclose sans vérifier la valeur de rétour (tandis qu'on
ne vérifiait jamais sur un fprintf, par exemple). Je me suis fait
rédressé les oreilles de l'avoir oublié une fois -- un
collègue a perdu une bonne partie de son fichier en conséquence.
Ça faisait partie du b a ba de la programmation sous Unix, bien avant
que je n'avais entendu parlé de C++.

|> Ca me paraît bizarre qu'il ait fait une erreur ;-)

Bof. C'est un type assez fort, mais c'est un être humain quand
même. C'est assez fréquent de trouver des erreurs dans des livres,
même des livres des auteurs compétents. Je trouve, d'ailleurs, que
c'est assez fréquent que lorsqu'un auteur explique une chose, il a
une tendance à oublier les autres aspects. Stroutrup s'en tire mieux
que la plupart à cet égard, mais ça ne veut pas dire qu'il est
parfait.

Le plus simple, c'est de lui écrire un email et le lui démander :
comment on fait pour vérifier des erreurs éventuelles detectées
lors de la fermaturer si la fermature a lieu dans le destructeur ?
(Et que penser de cette technique si on a paramètré les ostream
pour lever une exception en cas d'erreur ?) Il ne mord pas.

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

"Michaël Monerau" <cort@meloo.com> writes:

|> Arnaud Debaene wrote:
|> > Michaël Monerau wrote:
|> >> kanze@gabi-soft.fr wrote:
|> >>> On ne peut pas prendre la bibliothèque standard comme un
|> >>> modèle de bonne conception:-). Mais en l'occurance... il faut
|> >>> bien que le destructeur ferme tout et libère toutes ses
|> >>> ressources. En général, y compter est une erreur de
|> >>> programmation, mais je ne vois pas ce qu'il pourrait faire
|> >>> d'autre.

|> >> Pourquoi une erreur de programmation ? Je ne saisis pas bien...
|> >> Si ce comportement est normalisé, l'exploiter ne me paraît
|> >> pas être une erreur de programmation.

|> > S'il y a une erreur d'écriture sur le disque au moment du "close"
|> > dans le destructeur du fstream, tu as deux possiblités :
|> > - le fstream ignore silencieusement l'erreur, et le programmeur n'a
|> > aucun moyen de savoir qu'il y a eu une erreur.
|> > - le destructeur du fstream lève une exception, ce qu'il ne faut
|> > jamais faire et on entre gaillardement dans le domaine du
|> > comportement indéfini.

|> Je viens de lire une partie du chapitre sur les streams du
|> Stroustrup, voilà ce que j'y trouve :

|> # début citation #
|> §21.5.2 Closing of streams (p. 639)
|> A file can be explicitly closed by calling close() on its stream :

|> [exemple de code]

|> However, this is implicitly done by the streams's destructor. So an
|> explicit call of close() is needed only if the file must be closed
|> before reaching the end of the scope in which its stream was
|> declared.
|> # fin citation #
|>
|> Donc je me pose une question... Bjarne a-t-il occulté le
|> problème de l'exception levée dans un destructeur (qui, je le
|> rappelle au cas où, est interdit car sinon, on ne peut pas
|> remonter la pile d'appel) et les points que tu écris ci-dessus ?
|> Ou alors, à quoi pensait-il en contrepartie ?

Je ne sais pas. Je sais qu'en C, c'était très mauvause forme
d'appeler fclose sans vérifier la valeur de rétour (tandis qu'on
ne vérifiait jamais sur un fprintf, par exemple). Je me suis fait
rédressé les oreilles de l'avoir oublié une fois -- un
collègue a perdu une bonne partie de son fichier en conséquence.
Ça faisait partie du b a ba de la programmation sous Unix, bien avant
que je n'avais entendu parlé de C++.

|> Ca me paraît bizarre qu'il ait fait une erreur ;-)

Bof. C'est un type assez fort, mais c'est un être humain quand
même. C'est assez fréquent de trouver des erreurs dans des livres,
même des livres des auteurs compétents. Je trouve, d'ailleurs, que
c'est assez fréquent que lorsqu'un auteur explique une chose, il a
une tendance à oublier les autres aspects. Stroutrup s'en tire mieux
que la plupart à cet égard, mais ça ne veut pas dire qu'il est
parfait.

Le plus simple, c'est de lui écrire un email et le lui démander :
comment on fait pour vérifier des erreurs éventuelles detectées
lors de la fermaturer si la fermature a lieu dans le destructeur ?
(Et que penser de cette technique si on a paramètré les ostream
pour lever une exception en cas d'erreur ?) Il ne mord pas.

--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

Vous avez filtré cet utilisateur ! Consultez son message

"Michaël Monerau" writes:

|> Arnaud Debaene wrote:
|> > Michaël Monerau wrote:
|> >> wrote:
|> >>> On ne peut pas prendre la bibliothèque standard comme un
|> >>> modèle de bonne conception:-). Mais en l'occurance... il faut
|> >>> bien que le destructeur ferme tout et libère toutes ses
|> >>> ressources. En général, y compter est une erreur de
|> >>> programmation, mais je ne vois pas ce qu'il pourrait faire
|> >>> d'autre.

|> >> Pourquoi une erreur de programmation ? Je ne saisis pas bien...
|> >> Si ce comportement est normalisé, l'exploiter ne me paraît
|> >> pas être une erreur de programmation.

|> > S'il y a une erreur d'écriture sur le disque au moment du "close"
|> > dans le destructeur du fstream, tu as deux possiblités :
|> > - le fstream ignore silencieusement l'erreur, et le programmeur n'a
|> > aucun moyen de savoir qu'il y a eu une erreur.
|> > - le destructeur du fstream lève une exception, ce qu'il ne faut
|> > jamais faire et on entre gaillardement dans le domaine du
|> > comportement indéfini.

|> Je viens de lire une partie du chapitre sur les streams du
|> Stroustrup, voilà ce que j'y trouve :

|> # début citation #
|> §21.5.2 Closing of streams (p. 639)
|> A file can be explicitly closed by calling close() on its stream :

|> [exemple de code]

|> However, this is implicitly done by the streams's destructor. So an
|> explicit call of close() is needed only if the file must be closed
|> before reaching the end of the scope in which its stream was
|> declared.
|> # fin citation #
|>
|> Donc je me pose une question... Bjarne a-t-il occulté le
|> problème de l'exception levée dans un destructeur (qui, je le
|> rappelle au cas où, est interdit car sinon, on ne peut pas
|> remonter la pile d'appel) et les points que tu écris ci-dessus ?
|> Ou alors, à quoi pensait-il en contrepartie ?

Je ne sais pas. Je sais qu'en C, c'était très mauvause forme
d'appeler fclose sans vérifier la valeur de rétour (tandis qu'on
ne vérifiait jamais sur un fprintf, par exemple). Je me suis fait
rédressé les oreilles de l'avoir oublié une fois -- un
collègue a perdu une bonne partie de son fichier en conséquence.
Ça faisait partie du b a ba de la programmation sous Unix, bien avant
que je n'avais entendu parlé de C++.

|> Ca me paraît bizarre qu'il ait fait une erreur ;-)

Bof. C'est un type assez fort, mais c'est un être humain quand
même. C'est assez fréquent de trouver des erreurs dans des livres,
même des livres des auteurs compétents. Je trouve, d'ailleurs, que
c'est assez fréquent que lorsqu'un auteur explique une chose, il a
une tendance à oublier les autres aspects. Stroutrup s'en tire mieux
que la plupart à cet égard, mais ça ne veut pas dire qu'il est
parfait.

Le plus simple, c'est de lui écrire un email et le lui démander :
comment on fait pour vérifier des erreurs éventuelles detectées
lors de la fermaturer si la fermature a lieu dans le destructeur ?
(Et que penser de cette technique si on a paramètré les ostream
pour lever une exception en cas d'erreur ?) Il ne mord pas.

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

Michaël Monerau

21/09/2003 à 19:29

James Kanze wrote:

Ca me paraît bizarre qu'il ait fait une erreur ;-)

Bof. C'est un type assez fort, mais c'est un être humain quand
même. C'est assez fréquent de trouver des erreurs dans des livres,
même des livres des auteurs compétents. Je trouve, d'ailleurs, que
c'est assez fréquent que lorsqu'un auteur explique une chose, il a
une tendance à oublier les autres aspects. Stroutrup s'en tire mieux
que la plupart à cet égard, mais ça ne veut pas dire qu'il est
parfait.

Oui, c'est un type "assez fort" ;-) (euphémisme à mon goût :p). De toute
façon, sur un livre de volume si important, il est inévitable qu'il y ait
des erreurs... Mais il est lu par tellement de gens qu'on peu penser qu'il
n'y en aurait plus.

Le plus simple, c'est de lui écrire un email et le lui démander :
comment on fait pour vérifier des erreurs éventuelles detectées
lors de la fermaturer si la fermature a lieu dans le destructeur ?
(Et que penser de cette technique si on a paramètré les ostream
pour lever une exception en cas d'erreur ?) Il ne mord pas.

Ca va me faire tout bizarre d'écrire à M. Bjarne Stroustrup en personne ;-)
Mais il me reste à trouver son adresse email (que je ne trouve pas sur son
site...). Pourrais-tu me la faire parvenir par email () s'il
te plaît, si tu l'as ? Ce serait très sympa.

Merci.
--
<=- Michaël "Cortex" Monerau -=>

Arnaud Debaene

21/09/2003 à 20:43

Christophe Lephay wrote:

"Alain Naigeon" a écrit dans le message de
news:3f6d7d35$0$10407$
Du point de vue de celui qui écrit le destructeur, l'évènement
"destruction ordonnée par GC" est-il plus aléatoire - donc plus
problématique - que l'évènement "destruction suite à clic sur bouton
de fermeture" ?

Quelqu'un a dit (je sais plus qui) que tu n'avais pas la garantie que
le GC supprime effectivement l'objet, ce qui fait que le destructeur
n'est pas nécessairement appelé.

Ca c'est une limitation d'implémentation de Java (particulièrement stupide
AMHA) : Tu peux très bien écrire un GC qui appelle les finaliseurs de tous
les objets.

Arnaud

Arnaud Debaene

21/09/2003 à 20:46

Alain Naigeon wrote:

Oui, bon, je comprends ton exemple, mais comme d'autres l'ont
souligné,
il s'agit plus d'un problème de fond lié à ce cas que d'un problème de
langage.
On ne sait pas quand le destructeur est appelé, ok, mais il se peut
qu'il y ait tout de même des choses à faire en toutes circonstances,
et quel
que soit le moment où un objet est détruit. Alors ce code, j'imaginais
qu'on puisse le loger dans un "OnDelete", une sorte de programmation
évènementielle. Après tout, il y a plein de choses à faire pour
détruire une fenêtre, mais on ne sait pas non plus quand
l'utilisateur va cliquer pour la fermer. Alors il y a sans doute
quelque chose qui m'échappe...
Du point de vue de celui qui écrit le destructeur, l'évènement
"destruction ordonnée par GC" est-il plus aléatoire - donc plus
problématique - que l'évènement "destruction suite à clic sur bouton
de fermeture" ?

Quand tu reçoit l'événement "clic sur le bouton de fermeture de la fenêtre",
tu sais un certain nombre de choses, comme par exemple que toutes les
fenêtres filles (contenues dans ta fenêtre) ne sont pas encore détruites.
Par comparqison, ave cun GC, tu ne sais pas lequel du "o_file_stream" ou de
son buffer est détruit en premier. De plus, tous les événéments GUI se
produisent (généralement) dans un seul thread, alors que les finaliseurs
sont appelés le plus souvent dans un thread spécifique du GC.

Arnaud

kanze

22/09/2003 à 09:03

"Arnaud Debaene" wrote in message
news:<3f6c6165$0$2809$...

Gourgouilloult wrote:

Par contre, je n'ai plus fait de Java depuis des lustres...
quelqu'un peut me rappeler si toutes les méthodes ne sont pas
virtuelles, en Java ?

Par défaut elles sont virtuelles. Ont peut les rendre non virtuelles
avec final. Il n'est pas dit explicitement que les méthodes final ne
sont pas aussi appelées via la v-table, mais il est indiqué qu'elles
peuvent être inlinées, ce qui laisserait supposer qu'elles sont
effectivement appelées directement.

Comme en C++, la spécification de Java ne définit pas de mechanisme
(vptr, etc.) d'implémentation. Et il serait une erreur de faire
l'assimilation final == non-virtuelle.

Formellement, les seules fonctions non-virtuelles en Java sont des
fonctions privées. La sémantique de final, c'est d'intérdire à une
classe dérivée de rédéfinir la fonction. Par la suite, c'est une
question d'optimisation -- si on appelle la fonction à travers une
référence à la classe où elle est déclarée final, le compilateur sait
que la fonction ne serait pas rédéfinie, et donc, il sait de façon
statique exactement quelle fonction serait appelée. Dans ce cas, il
serait bien bête de passer par le mechanisme de résolution dynamique.
Mais le cas s'apparente au cas en C++ où on appelle une fonction
virtuelle, mais le compilateur connaît le type dynamique de l'objet, et
non au cas des fonctions non-virtuelles.

Il ne faut oublier non plus que si une classe est déclarée final, on ne
peut pas en dériver, et du coup, le compilateur sait également que ses
fonctions ne serait pas rédéfinies, et qu'il peut appliquer la même
optimisation à toutes les fonctions.

Enfin, les compilateurs modernes de Java n'ont pas besoin du mot clé
final pour effectuer ces optimisations. En gros, ils collectionnent des
statistiques d'exécution à fur et à mésure ; quand ils décident de
compiler une fonction en code natif, ils ne le compilent que pour des
cas déjà rencontrés, et ils ajoutent des tests en entrée qui déclenchent
une récompilation si ces préconditions ne valent pas.

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

"Arnaud Debaene" <adebaene@club-internet.fr> wrote in message
news:<3f6c6165$0$2809$626a54ce@news.free.fr>...

Gourgouilloult wrote:

Par contre, je n'ai plus fait de Java depuis des lustres...
quelqu'un peut me rappeler si toutes les méthodes ne sont pas
virtuelles, en Java ?

Par défaut elles sont virtuelles. Ont peut les rendre non virtuelles
avec final. Il n'est pas dit explicitement que les méthodes final ne
sont pas aussi appelées via la v-table, mais il est indiqué qu'elles
peuvent être inlinées, ce qui laisserait supposer qu'elles sont
effectivement appelées directement.

Comme en C++, la spécification de Java ne définit pas de mechanisme
(vptr, etc.) d'implémentation. Et il serait une erreur de faire
l'assimilation final == non-virtuelle.

Formellement, les seules fonctions non-virtuelles en Java sont des
fonctions privées. La sémantique de final, c'est d'intérdire à une
classe dérivée de rédéfinir la fonction. Par la suite, c'est une
question d'optimisation -- si on appelle la fonction à travers une
référence à la classe où elle est déclarée final, le compilateur sait
que la fonction ne serait pas rédéfinie, et donc, il sait de façon
statique exactement quelle fonction serait appelée. Dans ce cas, il
serait bien bête de passer par le mechanisme de résolution dynamique.
Mais le cas s'apparente au cas en C++ où on appelle une fonction
virtuelle, mais le compilateur connaît le type dynamique de l'objet, et
non au cas des fonctions non-virtuelles.

Il ne faut oublier non plus que si une classe est déclarée final, on ne
peut pas en dériver, et du coup, le compilateur sait également que ses
fonctions ne serait pas rédéfinies, et qu'il peut appliquer la même
optimisation à toutes les fonctions.

Enfin, les compilateurs modernes de Java n'ont pas besoin du mot clé
final pour effectuer ces optimisations. En gros, ils collectionnent des
statistiques d'exécution à fur et à mésure ; quand ils décident de
compiler une fonction en code natif, ils ne le compilent que pour des
cas déjà rencontrés, et ils ajoutent des tests en entrée qui déclenchent
une récompilation si ces préconditions ne valent 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

Vous avez filtré cet utilisateur ! Consultez son message

"Arnaud Debaene" wrote in message
news:<3f6c6165$0$2809$...

Gourgouilloult wrote:

Par contre, je n'ai plus fait de Java depuis des lustres...
quelqu'un peut me rappeler si toutes les méthodes ne sont pas
virtuelles, en Java ?

Par défaut elles sont virtuelles. Ont peut les rendre non virtuelles
avec final. Il n'est pas dit explicitement que les méthodes final ne
sont pas aussi appelées via la v-table, mais il est indiqué qu'elles
peuvent être inlinées, ce qui laisserait supposer qu'elles sont
effectivement appelées directement.

Comme en C++, la spécification de Java ne définit pas de mechanisme
(vptr, etc.) d'implémentation. Et il serait une erreur de faire
l'assimilation final == non-virtuelle.

Formellement, les seules fonctions non-virtuelles en Java sont des
fonctions privées. La sémantique de final, c'est d'intérdire à une
classe dérivée de rédéfinir la fonction. Par la suite, c'est une
question d'optimisation -- si on appelle la fonction à travers une
référence à la classe où elle est déclarée final, le compilateur sait
que la fonction ne serait pas rédéfinie, et donc, il sait de façon
statique exactement quelle fonction serait appelée. Dans ce cas, il
serait bien bête de passer par le mechanisme de résolution dynamique.
Mais le cas s'apparente au cas en C++ où on appelle une fonction
virtuelle, mais le compilateur connaît le type dynamique de l'objet, et
non au cas des fonctions non-virtuelles.

Il ne faut oublier non plus que si une classe est déclarée final, on ne
peut pas en dériver, et du coup, le compilateur sait également que ses
fonctions ne serait pas rédéfinies, et qu'il peut appliquer la même
optimisation à toutes les fonctions.

Enfin, les compilateurs modernes de Java n'ont pas besoin du mot clé
final pour effectuer ces optimisations. En gros, ils collectionnent des
statistiques d'exécution à fur et à mésure ; quand ils décident de
compiler une fonction en code natif, ils ne le compilent que pour des
cas déjà rencontrés, et ils ajoutent des tests en entrée qui déclenchent
une récompilation si ces préconditions ne valent pas.

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

Marc Boyer

22/09/2003 à 10:59

Arnaud Debaene wrote:

Christophe Lephay wrote:
"Alain Naigeon" a écrit dans le message de
news:3f6d7d35$0$10407$
Du point de vue de celui qui écrit le destructeur, l'évènement
"destruction ordonnée par GC" est-il plus aléatoire - donc plus
problématique - que l'évènement "destruction suite à clic sur bouton
de fermeture" ?

Quelqu'un a dit (je sais plus qui) que tu n'avais pas la garantie que
le GC supprime effectivement l'objet, ce qui fait que le destructeur
n'est pas nécessairement appelé.

Ca c'est une limitation d'implémentation de Java (particulièrement stupide
AMHA) : Tu peux très bien écrire un GC qui appelle les finaliseurs de tous
les objets.

Sauf que Java, ce n'est pas qu'un langage, c'est un langage + une
machine virtuelle. Et la portabilité de Java implique une forte
homogénéité entre les comportemets des VM.
Le GC fait partie de Java.

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Arnaud Meurgues

22/09/2003 à 11:27

Marc Boyer wrote:

Sauf que Java, ce n'est pas qu'un langage, c'est un langage + une
machine virtuelle. Et la portabilité de Java implique une forte
homogénéité entre les comportemets des VM.
Le GC fait partie de Java.

Je ne pense pas que faire un GC qui appellerait sûrement tous les
finaliseur ne soit pas conforme à la spécification Java.
En revanche, effectivement, on ne pourrait pas compter sur ce
comportement, puisque les programmes Java doivent pouvoir tourner sur
toutes les JVM.

Arnaud

Gabriel Dos Reis

23/09/2003 à 08:34

Marc Boyer writes:

| Mais avec Java, il te faudrait distribuer la JVM, et ça devient
| plus compliqué.

write once, debug everywhere.

-- Gaby

Jean-Marc Bourguet

23/09/2003 à 08:52

Marc Boyer writes:

Mais avec Java, il te faudrait distribuer la JVM, et ça devient
plus compliqué.

A ma connaissance -- je ne touche pas a cette partie -- c'est ce que
nous faisons pour ce qui est ecrit en Java.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Java vs C++

10 réponses

Veuillez sélectionner un problème