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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,591cbead201d7f34 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!s8g2000prg.googlegroups.com!not-for-mail From: Eric Hughes Newsgroups: comp.lang.ada Subject: Re: Prohibiting dynamic allocation for the given type Date: Thu, 20 Mar 2008 14:35:42 -0700 (PDT) Organization: http://groups.google.com Message-ID: <559ae479-2350-4818-a272-6b095d7cb8ae@s8g2000prg.googlegroups.com> References: <83335709-e099-416b-9967-5ab6aa0aea11@i12g2000prf.googlegroups.com> <89ac4348-4c21-478e-b491-97bfbebfdb86@p73g2000hsd.googlegroups.com> NNTP-Posting-Host: 166.70.57.218 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1206048943 7914 127.0.0.1 (20 Mar 2008 21:35:43 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 20 Mar 2008 21:35:43 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: s8g2000prg.googlegroups.com; posting-host=166.70.57.218; posting-account=5RIiTwoAAACt_Eu87gmPAJMoMTeMz-rn User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:20515 Date: 2008-03-20T14:35:42-07:00 List-Id: On Mar 19, 6:48 pm, Robert A Duff wrote: > Maybe you could give an outline of the code. I'll presume the as-yet-unpublished Strong_Access and Weak_Access (that's what I'm working on now) (think: like Boost shared_ptr and weak_ptr). Here's a bare outline. type X is null record ; -- nonce type package Smart_Access_to_X is new Smart_Access( X ) ; use Smart_Access_to_X ; -- type Object is contingent upon one of its components for some or all of its functionality type Object is record Lifetime : Weak_Access ; -- ... end record ; ... procedure Operation( Obj : in out Object ) is begin if ( Is_Null( Obj.Lifetime ) ) then return ; end if ; -- Assert Lifetime referent continues to exist -- ... end ; ... procedure Foo is Bar : Object_Access := new Object'( Lifetime => Null_Weak_Access ) ; -- Bar does not work, can't make it do anything. begin declare Sentry : Strong_Access := Construct_Strong_Access( Access_Value => new X ) ; begin Bar.all := Object'( Lifetime => Copy_As_Weak_Access( Strong_Accessor => Sentry ) ) ; -- Bar now works end -- Sentry is now out of scope; referent implicitly deallocated; weak reference to it is null; Bar has stopped working end > In particular, how do you ensure that the "sentry" is not heap-allocated? As I said in my original post, if you want scope lifetime, you need to instantiate a scope dependency. This technique does not enforce any particular lifetime policy. > If you trust the client on that, then why not trust > the client to avoid heap allocation for the "real" object in the > first place? The distinction here is that the original object still exists. Access values to it will remain valid. Depending on how the object is used, it might be necessary to have that. Personally, I can't imagine how this might be useful unless two or more tasks are at issue, say, passing a 'not null access all' parameter to a subprogram that assumes continued existence of the referent of its parameter. Since the dependency mechanism is generic, it would be just as possible to make the functional lifetime of a variable have the scope of some task. The original question was somewhat theoretical, as is this answer. Eric