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.

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

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.

<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

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