Re: Problems with controlled types, gnatmem thinks handle is leaking memory (long)

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 20 Feb 2005 23:09:15 +0000, Luke A. Guest wrote:

> On Sun, 20 Feb 2005 19:09:02 +0100, Dmitry A. Kazakov wrote:
> 
>> Minor comments:
>> 
>> In Finalize: I check if Ref_Count = 0 before decrementing and raise
> 
> No need to check for the reference count to be 0, as it can never go
> negative and if it does, there's a problem with the code.

That's the only reason why. (:-))
 
>> if the Ref_Count is zero upon object's finalization. That helps a lot!
> 
> I suppose I could raise an exception if the reference count isn't zero on
> finalisation, hmmm...but surely there would be an error in the code if
> that were not the case? Surely it's another example of what I mentioned
> above, it should never go wrong as long as the initialize, adjust &
> finalize subprograms have been implemented correctly.

Unfortunately smart pointers, even if implemented correctly, do not
warranty correct performance. A program still may [mis]use them in an
inappropriate way. A typical example is when an object directly or
indirectly holds a handle to itself, you could have a very long chain of
objects dependent on each other. It is highly desirable, but not always
possible to prevent this statically, per design.

A real-life example: I am using handles for object persistence. I need to
maintain a catalogue of all persistent objects resident in the memory. This
catalogue is itself an object that refers to a data base connection. Now
imagine, a persistent object, which is resident in that data base, so that
its memory counterpart is just a proxy to the data base. This object shall
refer to the data base connection object, otherwise that connection object
might vanish prematurely. But it also have to be in the catalogue. Boom! (I
added a complicated mechanism to break such dependencies in persistent
handles.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de