Re: Prohibiting dynamic allocation for the given type

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Eric Hughes <eric.eh9@gmail.com> 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