Eric Hughes <eric.eh9@[EMAIL PROTECTED]
> 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 do***ent 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
|
