Java vs C++

Richard Delorme <abulmo@nospam.fr> wrote in
news:3f696b48$0$20947$7a628cd7@news.club-internet.fr:

En java, les objets sont systématiquement passés par référence, et non
par copie, sauf les types natifs (boolean, int, ...).

Pas exactement car _tout_ est passé par valeur en Java ; et il n'y a pas
d'exception. C'est juste que les types "référence" sont en fait des
pointeurs vers des endroits qui contiennent plus que les objets (ie:
nombre des références qui pointent là et probablement une ou deux autres
infos).

Tu joues sur les mots ?

La spécification java dit (§4.3.1) :
« The reference values (often just references) are pointers to these
objects, and a special null reference, which refers to no object. »

Donc références ou valeurs "référence" sont deux synonymes, et on utilise
souvent juste le mot "référence". Et ce ne sont pas les types "référence"
qui sont des pointeurs, mais les valeurs "référence". Un type "référence"
est un type de classe, d'interface ou de tableau.

--
Richard - qui peut jouer sur les mots aussi.

kanze@gabi-soft.fr writes:

| > Du genre de ce que fait C# ?
|
| Je ne sais pas ce qu'on fait en C# -- jusqu'ici, il ne tourne pas sur
| mon Sparc.

C# refuse d'admettre que ton Sparc est le centre du système ? ;-/

-- Gaby

Arnaud Debaene wrote:

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

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

Il me semble que ca simplifie la sérialisation entre autres.

Je pense que l'introspection simplifie la sérialisation. C'est une chose
qui me manque en C++.
Par contre, le fait que tout dérive d'Object ne me semble pas trop lié...

--
Loïc

Luc Hermitte wrote:

Richard Delorme <abulmo@nospam.fr> wrote in
news:3f696b48$0$20947$7a628cd7@news.club-internet.fr:

En java, les objets sont systématiquement passés par référence, et
non par copie, sauf les types natifs (boolean, int, ...).

Pas exactement car _tout_ est passé par valeur en Java ; et il n'y a
pas d'exception. C'est juste que les types "référence" sont en fait
des pointeurs vers des endroits qui contiennent plus que les objets
(ie: nombre des références qui pointent là et probablement une ou
deux autres infos).

L'idée principale demeure : tu ne peux pas passer par valeur un objet autre
qu'un des types primitifs.

Arnaud

le Friday 19 September 2003 00:42, hermitte@free.fr.invalid écrivit :

Au passage, je suis tombé cette page assez sympa grâce à google :
<http://javadude.com/articles/passbyvalue.htm>

extrait :
In Java,
Dog d; // Java
is exactly like C or C++'s
Dog *d; // C++
And using
d.setName("Fifi"); // Java
is exactly like C++'s
d->setName("Fifi"); // C++

Si on fait la version C++, on déréférence un pointeur non-initialisé, donc
comportement indéfini et en pratique plantage probable.

C'est vraiment pareil en Java ? "Dog d;" déclare juste un pointeur, et il
faut appeler new explicitement pour obtenir de la mémoire et y créer un
objet ?

--
Sam

Samuel Krempp wrote:

le Friday 19 September 2003 00:42, hermitte@free.fr.invalid écrivit :

Au passage, je suis tombé cette page assez sympa grâce à google :
<http://javadude.com/articles/passbyvalue.htm>

extrait :
In Java,
Dog d; // Java
is exactly like C or C++'s
Dog *d; // C++
And using
d.setName("Fifi"); // Java
is exactly like C++'s
d->setName("Fifi"); // C++

Si on fait la version C++, on déréférence un pointeur non-initialisé,
donc comportement indéfini et en pratique plantage probable.

C'est vraiment pareil en Java ? "Dog d;" déclare juste un pointeur,
et il faut appeler new explicitement pour obtenir de la mémoire et y
créer un objet ?
Oui

Arnaud

"Arnaud Debaene" <adebaene@club-internet.fr> writes:

kanze@gabi-soft.fr wrote:

Imagines par exemple un objet "o_file_stream" gérant un fichier en
écriture. Cet objet contient en interne un objet "buffer" pour des
raisons de performances. La question est : comment s'assurer que
toutes les données sont bien écrites sur le disque au moment où
l'objet o_file_stream est détruit?

L'exemple est mal choisi, je crois. S'il faut s'assurer que tous les
données soient sur disque, il ne faut attendre ne finalize (en Java),
ne le destructeur en C++ (parce que qui dit écrire dit erreur
potentiel, et comment vas-tu traiter l'erreur dans le destructeur ?).

Oui et non : de toute façon, qu'est ce que tu peux faire en cas d'erreur
d'écriture sur disque, où que ce soit dans ton programme?

Ca depend naturellement de la nature du programme. Dans un programme
interactif, demander que faire a l'utilisateur. Dans un programme
tres robuste fonctionnant de maniere non interactive, on peut analyser
l'erreur (disque plein ou erreur d'ecriture, quel genre d'erreur,...)
et agir en consequence (notifier par SMS l'administrateur qu'un disque
est plein et continuer sur un autre disque par exemple ou bien effacer
les donnees les plus vieilles; pour une erreur autre que disque plein,
l'action peut etre differente bien sur).

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

Samuel Krempp <krempp@crans.truc.en.trop.ens-cachan.fr> wrote in message
news:<3f6a5cd5$0$27014$626a54ce@news.free.fr>...

le Friday 19 September 2003 00:42, hermitte@free.fr.invalid écrivit :

Au passage, je suis tombé cette page assez sympa grâce à google :
<http://javadude.com/articles/passbyvalue.htm>

extrait :
In Java,
Dog d; // Java
is exactly like C or C++'s
Dog *d; // C++
And using
d.setName("Fifi"); // Java
is exactly like C++'s
d->setName("Fifi"); // C++

Si on fait la version C++, on déréférence un pointeur non-initialisé,
donc comportement indéfini et en pratique plantage probable.

Tout à fait.

C'est vraiment pareil en Java ? "Dog d;" déclare juste un pointeur, et
il faut appeler new explicitement pour obtenir de la mémoire et y
créer un objet ?

Oui. La seule différence entre les deux, ici, réside dans le fait que la
spécification de Java exige que la variable soit initialisée avant
l'utilisation, ET que le compilateur peut le prouver, sinon il doit y
avoir une erreur à la compilation. (Puisque les variables non-locales
sont toujours initialisées à NULL par le compilateur, ce n'est que des
variables locales dont il est question.) Voir
http://java.sun.com/docs/books/jls/second_edition/html/defAssign.doc.html.

La plupart du temps, on suit les mêmes règles qu'en C : on initialise
dans la définition. :
Dog d = NULL ;
ou
Dog d = new Dog() ;

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

adebaene@club-internet.fr (Arnaud Debaene) wrote in message
news:<16a4a8c7.0309180728.7072138c@posting.google.com>...

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

Une ramasse-miettes serait une bonne chose en C++, il n'y a rien à
dire. Mais soyons précis : l'existance d'une ramasse-miettes est
orthogonale à la support pour l'OO (qui semblait intéresser surtout
le posteur initial), et c'est également orthogonale à l'existance
des destructeurs.

Il y a eu une proposition pour une ramasse-miettes en C++ présentée
au comité de normalisation avant la dernière norme. Les auteurs l'en
ont rétiré, parce qu'ils s'éstîmaient à l'époque que c'était trop
tard, et que essayer de l'incorporer au langage aurait rétardé la
norme. Je ne l'exclurais pas d'office dans la prochaine version de
la norme, même si d'autres évolutions semblent en avoir réduit
l'importance.

Quel serait le mode de fonctionnement de ce GC? Quand seraient appelés
les destructeurs des objets gérés par le GC, et avec quelles
contraintes? Si tu as une référence sur le sujet....

Ça dépend des avis. À mon avis, si un objet est ramassé par le GC, son
destructeur ne doit pas être appelé. (Ou inversement, si un objet a
besoin qu'on appelle son destructeur, il ne faut pas qu'il soit géré par
le GC.) Mais Hans Boehm (le véritable expert) n'est pas d'accord, ou au
moins est plus nuancé. Voir par exemple la question « What does a
garbage collector do about destructors? », dans la GC FAQ
(http://www.iecc.com/gclist/GC-faq.html) ou « Safe, Efficient Garbage
Collection for C++ », de Ellis et Detlefs
(http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-rr-102.html).

Ce qui est certain, c'est que des opérations qui doivent se faire à un
moment défini ne doivent pas se trouver dans le destructeur d'un objet
géré par la ramasse-miettes.

Il me semble que le "problème" du GC Java est qu'il gère
obligatoirement tous les objets (c'est lié à l'absence d'objets par
valeur).

C'est à peu près ça. Java n'a aucun support au niveau du langage pour
gérer la durée de vie des objets.

L'absence des destructeurs en Java est palié par les blocs finally.
Que l'utilisateur oublie systèmatiquement à mettre:-) -- dans ce
cas-ci, on pourrait dire que Java et C++ offrent les mêmes
possibilités, avec des moyens bien différents, mais que la façon C++
de faire est nettement plus robuste.

Oui : c'est anormal qu'une classe ait à se reposer sur le code client
pour garantir la libération de ses ressources privées.

Anormal ? Je dirais plutôt que c'est la norme, et que c'est le C++ qui
est l'exception.

Être la norme, évidemment, ne veut pas dire que c'est bon.

[...]

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

Il me semble que ca simplifie la sérialisation entre autres.

En quoi ? C'est éventuellement avantageux que tous les objets
sérialisables dérived d'une base commune, et encore. Je verrai plutôt
plusieurs bases : PersistentObject (qui peut s'écrire sur disque),
MigratableObject (qui peut se déplacer d'une machine à l'autre), etc.
Quant aux types attributes (p.e. std::string), qu'on copie à droit et à
gauche, je ne vois pas de besoin d'une base commune du tout.

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

kanze@gabi-soft.fr writes:

adebaene@club-internet.fr (Arnaud Debaene) wrote in message
news:<16a4a8c7.0309180728.7072138c@posting.google.com>...

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

Une ramasse-miettes serait une bonne chose en C++, il n'y a rien
à dire. Mais soyons précis : l'existance d'une ramasse-miettes
est orthogonale à la support pour l'OO (qui semblait intéresser
surtout le posteur initial), et c'est également orthogonale à
l'existance des destructeurs.

Il y a eu une proposition pour une ramasse-miettes en C++
présentée au comité de normalisation avant la dernière
norme. Les auteurs l'en ont rétiré, parce qu'ils s'éstîmaient à
l'époque que c'était trop tard, et que essayer de l'incorporer
au langage aurait rétardé la norme. Je ne l'exclurais pas
d'office dans la prochaine version de la norme, même si d'autres
évolutions semblent en avoir réduit l'importance.

Quel serait le mode de fonctionnement de ce GC? Quand seraient
appelés les destructeurs des objets gérés par le GC, et avec
quelles contraintes? Si tu as une référence sur le sujet....

Ça dépend des avis. À mon avis, si un objet est ramassé par le GC,
son destructeur ne doit pas être appelé. (Ou inversement, si un
objet a besoin qu'on appelle son destructeur, il ne faut pas qu'il
soit géré par le GC.) Mais Hans Boehm (le véritable expert) n'est
pas d'accord, ou au moins est plus nuancé.

Une alternative a la finalisation (appelee par le GC -- et en
opposition a la destruction synchrone des destructeurs de C++, je ne
suis pas sur que cette nomemclature soit universelle, mais elle aide
au moins a s'exprimer clairement) est la notification de gestionnaires
qu'un objet donne n'a plus que references que chez les gestionnaires.
C'est plus facile de voir ce qui se passe si on faire "revivre" un
objet, mais en divisant l'objet en deux on peut voir que passer de
l'un a l'autre est facile.

Voir par exemple la question « What does a garbage collector do
about destructors? », dans la GC FAQ
(http://www.iecc.com/gclist/GC-faq.html) ou « Safe, Efficient
Garbage Collection for C++ », de Ellis et Detlefs
(http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-rr-102.html).

Ce qui est certain, c'est que des opérations qui doivent se faire à
un moment défini ne doivent pas se trouver dans le destructeur d'un
objet géré par la ramasse-miettes.

Il faut noter que certains des problemes existants avec la
finalisation existent aussi avec des objets a comptage de reference.
La question fondamentale est "quel est le contexte dans lequel est
appele le finaliseur/destructeur et qu'est-ce qu'il peut faire". Dans
le cadre d'un programme multithread "est-ce qu'il peut acquerir des
mutex?" En fait c'est plus facile a faire pour des finaliseurs (on
les exectutent dans un thread a eux et ils font ce qu'ils veulent,
pour le destructeur declanche par comptage de reference ce n'est pas
une solution possible).

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