Re: Prohibiting dynamic allocation for the given type

[Eric Hughes <eric.eh9@gmail.com>]

On Mar 19, 6:48 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
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