- En Java, tout le monde hérite d'Object. Il y a du pour et du contre... Intéressant. Je n'ai pas encore trouver du pour.
Ben si : sans ça, on aurait pas de containers en Java... ;-)
Arnaud
kanze
Arnaud Meurgues wrote in message news:<3f6acf98$0$2785$...
Luc Hermitte wrote:
Pas exactement car _tout_ est passé par valeur en Java ;
En C et en C++ aussi, si tu vas par là.
Quand le paramètre est une référence (en C++), il y a passe par référence. Dans tous les autres cas, y compris des pointeurs, il y a passe par valeur.
Ce que fait Java correspond à le passage d'un pointeur.
-- 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 Meurgues <arnaud@meurgues.non.fr.invalid> wrote in message
news:<3f6acf98$0$2785$626a54ce@news.free.fr>...
Luc Hermitte wrote:
Pas exactement car _tout_ est passé par valeur en Java ;
En C et en C++ aussi, si tu vas par là.
Quand le paramètre est une référence (en C++), il y a passe par
référence. Dans tous les autres cas, y compris des pointeurs, il y a
passe par valeur.
Ce que fait Java correspond à le passage d'un pointeur.
--
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
Arnaud Meurgues wrote in message news:<3f6acf98$0$2785$...
Luc Hermitte wrote:
Pas exactement car _tout_ est passé par valeur en Java ;
En C et en C++ aussi, si tu vas par là.
Quand le paramètre est une référence (en C++), il y a passe par référence. Dans tous les autres cas, y compris des pointeurs, il y a passe par valeur.
Ce que fait Java correspond à le passage d'un pointeur.
-- 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
Michaël Monerau
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. -- <=- Michaël "Cortex" Monerau -=>
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.
--
<=- Michaël "Cortex" Monerau -=>
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. -- <=- Michaël "Cortex" Monerau -=>
Arnaud Debaene
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.
Arnaud
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.
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.
Arnaud
Michaël Monerau
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.
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.
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.
"Arnaud Debaene" wrote in message news:<3f68cd83$0$2787$... <snip>
- En Java, tout le monde hérite d'Object. Il y a du pour et du contre...
Intéressant. Je n'ai pas encore trouver du pour.
Palier l'absence de template ?
Arnaud Debaene
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. voir : http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#11246
Arnaud
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.
voir :
http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#11246
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. voir : http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#11246
Arnaud
Alain Naigeon
"Arnaud Debaene" a écrit dans le message news:
"Alain Naigeon" wrote in message news:<3f68d0f2$0$10431$...
"Arnaud Debaene" a écrit dans le message news:
3f68cd83$0$2787$
- Garbage Collector en Java, ce qui entraine malheureusemeent qu'il n'y a
pas de vrai destructeur en Java
Ce qui entraîne..? Bon, il me semble qu'on peut imaginer de spécifier des destructeurs pris en compte par un Garbage collector (sans pour autant
déclencher soi-même leur exécution). Bien sûr, et ca existe en Java : ca s'appelle les finaliseurs. Le gros
problème est qu'ils sont appelés par le GC quand il détriut l'objet, ce qui signifie que tu ne sais pas quand il est appelé ni dans quel ordre.
Imagines par exemple un objet "o_file_stream" gérant un fichier en écriture. [...]
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" ?
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Arnaud Debaene" <adebaene@club-internet.fr> a écrit dans le message news:
16a4a8c7.0309180006.6344ecff@posting.google.com...
"Alain Naigeon" <anaigeon@free.fr> wrote in message
news:<3f68d0f2$0$10431$626a54ce@news.free.fr>...
"Arnaud Debaene" <adebaene@club-internet.fr> a écrit dans le message
news:
3f68cd83$0$2787$626a54ce@news.free.fr...
- Garbage Collector en Java, ce qui entraine malheureusemeent qu'il
n'y a
pas de vrai destructeur en Java
Ce qui entraîne..? Bon, il me semble qu'on peut imaginer de spécifier
des destructeurs pris en compte par un Garbage collector (sans pour
autant
déclencher soi-même leur exécution).
Bien sûr, et ca existe en Java : ca s'appelle les finaliseurs. Le gros
problème est qu'ils sont appelés par le GC quand il détriut l'objet,
ce qui signifie que tu ne sais pas quand il est appelé ni dans quel
ordre.
Imagines par exemple un objet "o_file_stream" gérant un fichier en
écriture.
[...]
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" ?
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
"Alain Naigeon" wrote in message news:<3f68d0f2$0$10431$...
"Arnaud Debaene" a écrit dans le message news:
3f68cd83$0$2787$
- Garbage Collector en Java, ce qui entraine malheureusemeent qu'il n'y a
pas de vrai destructeur en Java
Ce qui entraîne..? Bon, il me semble qu'on peut imaginer de spécifier des destructeurs pris en compte par un Garbage collector (sans pour autant
déclencher soi-même leur exécution). Bien sûr, et ca existe en Java : ca s'appelle les finaliseurs. Le gros
problème est qu'ils sont appelés par le GC quand il détriut l'objet, ce qui signifie que tu ne sais pas quand il est appelé ni dans quel ordre.
Imagines par exemple un objet "o_file_stream" gérant un fichier en écriture. [...]
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" ?
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
