From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,714a9fe4718c9803 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!proxad.net!proxad.net!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Problems with controlled types, gnatmem thinks handle is leaking memory (long) Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1s73d5wqz8pme.1m22aqftdn6ij.dlg@40tude.net> Date: Mon, 21 Feb 2005 09:49:21 +0100 Message-ID: <137k80rllxyi0.vflpkn5il5t7$.dlg@40tude.net> NNTP-Posting-Date: 21 Feb 2005 09:46:44 MET NNTP-Posting-Host: 9f48ec8e.newsread2.arcor-online.net X-Trace: DXC=J4mT5;PoeA3cbQG5oOHD^6Q5U85hF6f;4jW\KbG]kaM8ea\9g\;7Nm5UH56?2JjJC4[6LHn;2LCV>7enW;^6ZC`4<=9bOTW=MN> X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:8435 Date: 2005-02-21T09:46:44+01:00 List-Id: 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