🚀 go-pugleaf

Hi!

The objects that get out of scope simply disappear.
You can get the destructor called, if you implement a finalizer, but
is only recommended for smaller amount of objects and does
not work very well.

Regards!
Atmapuri

"Ender" <linuxmustdie@hotmail.com> wrote in message 
news:484fb37e$1@newsgroups.borland.com...
> Hello all.
>
> I'm confused. When object goes out of scope does it's destructor called or 
> not?
>
> 

"Atmapuri" <janez.makovsek@usa.net>
> The objects that get out of scope simply disappear.
> You can get the destructor called, if you implement a finalizer, but
> is only recommended for smaller amount of objects and does
> not work very well.

Does it mean that if we have destructor filled with code then we must call 
it from finalizer explicitly?

Atmapuri wrote:

> You can get the destructor called, if you implement a finalizer, but
> is only recommended for smaller amount of objects and does
> not work very well.

	This is very misleading.  Destructors are not finalizers.  In Delphi
for .NET, a destructor is an IDisposable implementation.  Yes, a
finalizer will eventually call this, but a finalizer is the worst
possible way to dispose of an object.

	The simple answer to the question is that no, destructors are not
automatically called.  If you need a destructor called at all (in many
cases, you don't) then you should use the IDisposable pattern.
Finalizers should be reserved for special cases like ensuring clean up
of unmanaged resources.

-- 
Craig Stuntz [TeamB] � Vertex Systems Corp. � Columbus, OH
  Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
IB 6 versions prior to 6.0.1.6 are pre-release and may corrupt 
  your DBs!  Open Edition users, get 6.0.1.6 from http://mers.com

Ender wrote:

> Hello all.
> 
> I'm confused. When object goes out of scope does it's destructor
> called or not?

No. 

You should know that the concept of a destructor is quite different in
.NET. In .NET, the destructors Destroy Delphi objects have map to
IDisposable.Dispose(, IOW, if an object has a destructor, the compiler
makes it implement IDisposable and maps the Dispose() method to the
destructor.

This is not called automatically, though. You'll still have to use try
finally and Free if you want to protect any resources other than memory.

You can give a .NET object a finalizer, called Finalize, but that is
called at some indeterminate time when the GC collects the object. It
is generally not a good idea to do that, though, since such objects
require special handling from the GC.

-- 
Rudy Velthuis [TeamB]        http://www.teamb.com

"Give me a museum and I'll fill it."
-- Pablo Picasso (1881-1973)

"Rudy Velthuis [TeamB]" <newsgroups@rvelthuis.de> wrote in message 
news:xn0frbtj1000000snewsgroups@rvelthuis.de...
> You should know that the concept of a destructor is quite different in
> .NET. In .NET, the destructors Destroy Delphi objects have map to
> IDisposable.Dispose(, IOW, if an object has a destructor, the compiler
> makes it implement IDisposable and maps the Dispose() method to the
> destructor.
>
> This is not called automatically, though. You'll still have to use try
> finally and Free if you want to protect any resources other than memory.
>
> You can give a .NET object a finalizer, called Finalize, but that is
> called at some indeterminate time when the GC collects the object. It
> is generally not a good idea to do that, though, since such objects
> require special handling from the GC.

Then we need to write and call destructors manually anyway. Correct? Any 
descendant of class can contain destructor which does something even if 
parent doesn't have one. We cannot call this destructor from Finalize 
because it might not work properly (different thread, uncertain time of 
call) and we cannot to simply "forget" about instance of this because it 
might be necessary to call its destructor. Then we need same old good style 
with try...finally. No, I really don't understand what is the advantage of 
GC then?

Ender wrote:

> Then we need to write and call destructors manually anyway. Correct?

	Mostly, no. 

http://dn.codegear.com/article/29365

-- 
Craig Stuntz [TeamB] � Vertex Systems Corp. � Columbus, OH
  Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Please read and follow Borland's rules for the user of their 
  server: http://support.borland.com/entry.jspa?externalID=293

"Ender" <linuxmustdie@hotmail.com> wrote in message 
news:485bf861@newsgroups.borland.com...
> Then we need to write and call destructors manually anyway. Correct? Any 
> descendant of class can contain destructor which does something even if 
> parent doesn't have one. We cannot call this destructor from Finalize 
> because it might not work properly (different thread, uncertain time of 
> call) and we cannot to simply "forget" about instance of this because it 
> might be necessary to call its destructor. Then we need same old good 
> style with try...finally. No, I really don't understand what is the 
> advantage of GC then?

Unless there are resources, other than normal memory, such as database or 
external connections, device handles, etc, then there is no need to worry 
about disposing your objects *now*, that is the point. .Net will dispose of 
them when convenient, which means better performance generally, and less 
worry about memory in your application.

IOW, needing to provide a destructor for your own classes should be rare.

-- 
Wayne Niddery - TeamB (www.teamb.com)
Winwright, Inc. (www.winwright.ca) 

Wayne Niddery (TeamB) wrote:

> IOW, needing to provide a destructor for your own classes should be
> rare.

Unless your class uses resources (DB connections, files, streams,
handles, device contexts, etc.) other than memory. Is that so seldom?

-- 
Rudy Velthuis [TeamB]        http://www.teamb.com

"The President has kept all of the promises he intended to keep."
 -- Clinton aide George Stephanopolous speaking on Larry 
    King Live

"Rudy Velthuis [TeamB]" <newsgroups@rvelthuis.de> wrote in message 
news:xn0frogmc000000enewsgroups@rvelthuis.de...
>
> Unless your class uses resources (DB connections, files, streams,
> handles, device contexts, etc.) other than memory. Is that so seldom?


I certainly design classes that do these things, but
1) I make sure such things are isolated in a small set of classes (e.g. 
database connections can be managed by a single instance of a single class).
2) In many cases such things do not need to be left open long, they are 
opened, used, and closed in a single method or a single process (spanning 
any number of methods), and so still don't need to be disposed of via a 
destructor (and I've generally coded that way on Win32 all along anyway).
3) they are still greatly outnumbered by classes that need none of these 
things.


-- 
Wayne Niddery - TeamB (www.teamb.com)
Winwright, Inc. (www.winwright.ca) 

>> Ender wrote:
>> Then we need to write and call destructors manually anyway. Correct?


>"Craig Stuntz [TeamB]" <craig_stuntz@nospam.please [a.k.a. acm.org]> wrote 
>in message news:485c1224$1@newsgroups.borland.com...
> Mostly, no.
>
> http://dn.codegear.com/article/29365

Thank you for the article. It was very interesting. My main concern is that 
we have two finalization styles deterministic and non-deterministic. Class 
(because of its implementation) may require deterministic finalization or 
may not require deterministic finalization. Please notice word 
"implementation". Class with non-deterministic finalization could become a 
class with deterministic finalization when its destructor is overriden. Thus 
a user of class instance must rely on the knowledge of class 
implementation - to call destructor or not to call. I think it is against of 
the OOP programming principles, implementation should be hidden from users 
of a class.

For example:

Declaration.

type

  TClassA=class(TObject)  // non-deterministic finalization Ok
  ...
  end;

  TClassB=class(TClassA) // non-deterministic finalization Ok
  ...
  end;

  TClassC=class(TClassA) // deterministic finalization required
  public
    destructor Destroy; override;
  end;

  destructor TClassC.Destroy;
  begin
    // do something that is required by a deterministic finalization pattern
  end;

Usage:

var
  MyInstance:TClassA;
begin
  MyInstance:=ClassFactory.CreateMyInstance(...); // ClassFactory creates 
either TClassB or TClassC
  ... do something useful with MyInstance
  // do we need to call MyInstance.Free or not????
  // MyInstance.Free;
end;

The problem is here. We need to know if MyInstance requires deterministic 
finalization or not, but we cannot be sure that ClassFactory always will 
create instance with non-deterministic finalization. Either we call Free 
always, or we not in safety!!!