www.digitalmars.com         C & C++   DMDScript  

D - Destructors and GC

reply 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. 
 
Sep 02 2003
next sibling parent 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
Sep 02 2003
prev sibling next sibling parent "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.

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

 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

 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.

Sep 02 2003
prev sibling parent reply "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.

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

 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

 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
Sep 02 2003
parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 As others have mentioned, you can manually delete it or use 'auto'.  If

 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

 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

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

 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

Sep 02 2003