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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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!news1.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Prohibiting dynamic allocation for the given type Date: Wed, 19 Mar 2008 20:48:18 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <83335709-e099-416b-9967-5ab6aa0aea11@i12g2000prf.googlegroups.com> <89ac4348-4c21-478e-b491-97bfbebfdb86@p73g2000hsd.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1205974099 3026 192.74.137.71 (20 Mar 2008 00:48:19 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Thu, 20 Mar 2008 00:48:19 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:FrMhdnVpWKbVb+tXJWi6O1wlqDw= Xref: g2news1.google.com comp.lang.ada:20499 Date: 2008-03-19T20:48:18-04:00 List-Id: Eric Hughes writes: > If you want to control lifetime, you can control either the allocation > lifetime or the functional lifetime; the second is a subset of the > first. As you've pointed out, you don't get a lot of control over > allocation lifetime. But functional lifetime you can control. Here's > how I would approach it. > > First, make the utility of your type depend for its function on the > existence of some other object. This likely goes into a constructor > function, but need not. Your type would contain some kind of a weak > accessor, one that doesn't enforce the existence of its referent. > Gate all utility upon the existence of this referent. If the referent > is absent, do nothing or throw an exception, whatever. This check is > cheap; it's that some access value is not null. Use finalization in > the referent to update the accessor value in your type. This gives > you a dependency between objects, regardless of how the referent > object is allocated. > > Second, when instantiating the object, make it refer to a sentry > object with block scope. When the sentry object goes out of scope, > your original object will stop working. I frequently use nested > declare/begin/end blocks within subprogram definitions to trigger > sentry finalization. > > You'll still have to document that if you want scope lifetime for your > object's utility, you'll have to make it dependent upon a scoped > variable. But at that point the code explicitly captures an intention > for scope lifetime. I don't understand this method. Maybe you could give an outline of the code. In particular, how do you ensure that the "sentry" is not heap-allocated? 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? I must be missing something... - Bob