James.Kanze@dresdner-bank.com writes:

> Correct.  And for a program designed with garbage collection in mind,
> I would make collecting an object with a non-trivial destructor an error
> condition.  (Of course, with garbage collections, about 95% of my
> destructors become trivial:-).)

In Java, objects can have finalize methods, which are invoked when
they get collected. I see nothing wrong with that concept.

In languages with garbage collection and no finalizers
(e.g. Smalltalk), users typically complain that they need
finalization.

Of course, there are finer semantical points: what do you do when the
finalizer brings an object back to life? But there are answers to
those questions, as well.

I think that true garbage collection for C++ should provide for
finalization. The most natural approach would be to invoke the
destructor. Of course, this would give a different language.

Regards,
Martin


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Martin von Loewis wrote:
>
> James.Kanze@dresdner-bank.com writes:
>
> > Correct.  And for a program designed with garbage collection in mind,
> > I would make collecting an object with a non-trivial destructor an error
> > condition.  (Of course, with garbage collections, about 95% of my
> > destructors become trivial:-).)
>
> In Java, objects can have finalize methods, which are invoked when
> they get collected. I see nothing wrong with that concept.

Objects aren't necessarily ever collected. The default is that when the
application exits, finalize is not called on any remaining objects. Even
of the finalize method is called, there is no assurance of when it will
be called. Any time-dependent cleanup must be performed manually.

>
> In languages with garbage collection and no finalizers
> (e.g. Smalltalk), users typically complain that they need
> finalization.

Well, maybe, but is their complaint that they need what Java provides,
or do they need some reliable mechanism for calling a member function
when an object is no longer in use?

>
> Of course, there are finer semantical points: what do you do when the
> finalizer brings an object back to life? But there are answers to
> those questions, as well.
>
> I think that true garbage collection for C++ should provide for
> finalization. The most natural approach would be to invoke the
> destructor. Of course, this would give a different language.
>

Yes, one in which you could not use destructors reliably, because you
could not be sure of when or if the destructor would be executed.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <p6qaeqvhorw.fsf@informatik.hu-berlin.de>,
  Martin von Loewis <loewis@informatik.hu-berlin.de> wrote:
>
> James.Kanze@dresdner-bank.com writes:

> > Correct.  And for a program designed with garbage collection in
> > mind, I would make collecting an object with a non-trivial
> > destructor an error condition.  (Of course, with garbage
> > collections, about 95% of my destructors become trivial:-).)

> In Java, objects can have finalize methods, which are invoked when
> they get collected. I see nothing wrong with that concept.

I see nothing wrong with it, but I see no real use for it either.  Since
the function gets called at an effectively random time, in an unknown
thread, there is not really much useful that it can do, other than
signal that there is an error in the program.

> In languages with garbage collection and no finalizers
> (e.g. Smalltalk), users typically complain that they need
> finalization.

The few Smalltalk users I know don't complain:-).

> Of course, there are finer semantical points: what do you do when the
> finalizer brings an object back to life? But there are answers to
> those questions, as well.

> I think that true garbage collection for C++ should provide for
> finalization. The most natural approach would be to invoke the
> destructor. Of course, this would give a different language.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <nIRceHAV$r13EwYJ@robinton.demon.co.uk>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
>
> In article <37D6AC42.23F4@wanadoo.fr>, Valentin Bonnard
> <Bonnard.V@wanadoo.fr> writes
> >What don't you understand ? A gc is about not having
> >to call delete manually. A gc should used if
> >programmers:
> >
> >- don't want to think about when delete should be
> >  called (maybe they consider that it's a waste of
> >  their time)
> >
> >- aren't confident enough in themselves to call delete
> >  when needed

> NO.  GC in general only handles memory release delete first calls a
> dtor and then releases memory.  Of course you might provide a more
> complicated type of GC that called dtors first but that is not
> necessary for GC as such.

Correct.  And for a program designed with garbage collection in mind,
I would make collecting an object with a non-trivial destructor an error
condition.  (Of course, with garbage collections, about 95% of my
destructors become trivial:-).)

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37D6AC42.23F4@wanadoo.fr>, Valentin Bonnard
<Bonnard.V@wanadoo.fr> writes
>What don't you understand ? A gc is about not having
>to call delete manually. A gc should used if
>programmers:
>
>- don't want to think about when delete should be
>  called (maybe they consider that it's a waste of
>  their time)
>
>- aren't confident enough in themselves to call delete
>  when needed

NO.  GC in general only handles memory release delete first calls a dtor
and then releases memory.  Of course you might provide a more
complicated type of GC that called dtors first but that is not necessary
for GC as such.

Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]