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!news1.google.com!postnews.google.com!c19g2000prf.googlegroups.com!not-for-mail From: Eric Hughes Newsgroups: comp.lang.ada Subject: Re: Prohibiting dynamic allocation for the given type Date: Wed, 19 Mar 2008 09:37:46 -0700 (PDT) Organization: http://groups.google.com Message-ID: 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 1205944666 10195 127.0.0.1 (19 Mar 2008 16:37:46 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 19 Mar 2008 16:37:46 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: c19g2000prf.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:20490 Date: 2008-03-19T09:37:46-07:00 List-Id: On Mar 19, 2:24 am, Maciej Sobczak wrote: > X : Type; > Y : Type_Ptr := new Type; [...] > For some types I might want to prohibit one of these two ways of > object creation. You can't prohibit the object creation itself, but you can make such an object useless. > If these two methods are available, then apparently there is a > difference between them and this difference is not in *where* objects > are created, but *how long* they are allowed to live. 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. Eric