• nospambjorn netinsight.nospam.se (30/30) Sep 02 2003 I'm a little concerned about the combination of destructors and garbage
• Helmut Leitner (8/24) Sep 02 2003 This is the Java situation, but not so in D.
• Sean L. Palmer (9/33) Sep 02 2003 You can also manually 'delete' the object.
• Scott McCaskill (21/43) Sep 02 2003 When
• Philippe Mori (19/35) Sep 02 2003 IMO, we should allows class declared auto to be at least a member of

nospambjorn netinsight.nospam.se writes:

I'm a little concerned about the combination of destructors and garbage
collection, and I wonder 
about D in this respect. 
 
The example 
 
I have an
object, whose representation is that of a network connection to a server. When
the 
object is created it establishes the connection. The destructor signals the
server to shut down 
the connection. 
 
As I understand it, it will not be
possible to know when the connection will be shut down. 
 
This is not a major
problem, since it's easy to add a member function "shutdown" that does the 
job,
but then that is not very different from manually releasing the object so it
feels like little is 
gained. 
 
Am I missing something fundamental here, or am
I helped only when the destructor does not have 
observeable side effects (which
I guess is the only reason to really have one?) 
   _ 
/Bjorn. 
 

Helmut Leitner <leitner hls.via.at> writes:

nospambjorn netinsight.nospam.se wrote:
 
 I'm a little concerned about the combination of destructors and garbage
 collection, and I wonder
 about D in this respect.
 
 The example
 
 I have an
 object, whose representation is that of a network connection to a server. When
 the
 object is created it establishes the connection. The destructor signals the
 server to shut down
 the connection.
 
 As I understand it, it will not be
 possible to know when the connection will be shut down.

This is the Java situation, but not so in D.

I think you can use the 'auto' keyword to make the compiler finalize the object 
when it goes out of scope. This should then include shutting down the
connection.
The memory block itself will be garbage collected at some time later on.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com

"Sean L. Palmer" <palmer.sean verizon.net> writes:

You can also manually 'delete' the object.

Garbage collection, it seems, is good for memory but not so much for other
resources.

Sean

<nospambjorn netinsight.nospam.se> wrote in message
news:bj1k62$1csd$1 digitaldaemon.com...
 I'm a little concerned about the combination of destructors and garbage
 collection, and I wonder
 about D in this respect.

 The example

 I have an
 object, whose representation is that of a network connection to a server.

When
 the
 object is created it establishes the connection. The destructor signals

the
 server to shut down
 the connection.

 As I understand it, it will not be
 possible to know when the connection will be shut down.

 This is not a major
 problem, since it's easy to add a member function "shutdown" that does the
 job,
 but then that is not very different from manually releasing the object so

it
 feels like little is
 gained.

 Am I missing something fundamental here, or am
 I helped only when the destructor does not have
 observeable side effects (which
 I guess is the only reason to really have one?)
    _
 /Bjorn.

"Scott McCaskill" <scott mccaskill.org> writes:

<nospambjorn netinsight.nospam.se> wrote in message
news:bj1k62$1csd$1 digitaldaemon.com...
 I'm a little concerned about the combination of destructors and garbage
 collection, and I wonder
 about D in this respect.

 The example

 I have an
 object, whose representation is that of a network connection to a server.

When
 the
 object is created it establishes the connection. The destructor signals

the
 server to shut down
 the connection.

 As I understand it, it will not be
 possible to know when the connection will be shut down.

 This is not a major
 problem, since it's easy to add a member function "shutdown" that does the
 job,
 but then that is not very different from manually releasing the object so

it
 feels like little is
 gained.

 Am I missing something fundamental here, or am
 I helped only when the destructor does not have
 observeable side effects (which
 I guess is the only reason to really have one?)

As others have mentioned, you can manually delete it or use 'auto'.  If you
declare the class as auto, then the compiler will require that all
references to instances of that class also be declared auto.  However, be
advised that it won't allow you to declare member variables as auto.  This
means that if you declare a class to be auto, it (or rather, references to
it) can never be a member variable.

To me, that seems like a pretty major restriction, especially where RAII
classes are concerned.  So the workaround is: don't declare classes as auto.
But then, clients of the class must (manually) remember to always use auto
whenever they declare a reference to my class, except when the reference is
a member variable, in which case they can't use auto and they must remember
to use delete in the class destructor.

At least, these are my experiences with the current compiler; am I missing
something?  How set-in-stone is the current behavior?

-- 
Scott McCaskill

"Philippe Mori" <philippe_mori hotmail.com> writes:

 As others have mentioned, you can manually delete it or use 'auto'.  If

you
 declare the class as auto, then the compiler will require that all
 references to instances of that class also be declared auto.  However, be
 advised that it won't allow you to declare member variables as auto.  This
 means that if you declare a class to be auto, it (or rather, references to
 it) can never be a member variable.

IMO, we should allows class declared auto to be at least a member of
another class declared auto (I don't think this could cause any problem)
and it would allows them to be used for RAII in the context of another
class... Maybe this is less important in D than in C++... I'm not sure how
constructors works in D.

Also, talking of constructor, I think we should have a way to ensure that
an instance is never null by having a way to prevent declaring an
unconstructed object reference (as it is the case with C++ reference
and constant data member). This would be a modifier like auto for a
class in the sense that declaring a class with it would ensure that
no null class of that type could ever exists...

 To me, that seems like a pretty major restriction, especially where RAII
 classes are concerned.  So the workaround is: don't declare classes as

auto.
 But then, clients of the class must (manually) remember to always use auto
 whenever they declare a reference to my class, except when the reference

is
 a member variable, in which case they can't use auto and they must

remember
 to use delete in the class destructor.

IMO, I think we should be able to declare auto variable as a member
of any classes (and for sure auto ones). Maybe there should be some
restriction of those classes relating to the possibility of copying them
for example...

 At least, these are my experiences with the current compiler; am I missing
 something?  How set-in-stone is the current behavior?

 -- 
 Scott McCaskill