Re: Objects and the Stack?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 18 Dec 2004 20:50:47 GMT, Freejack wrote:

> On Sat, 18 Dec 2004 14:41:33 -0500, Warren W. Gay VE3WWG wrote:
> 
>> The difference between what alloca() gets you and what you
>> get in the declare block is a minor difference:
>> 
>>     -- Pseudo Ada here (Ada-ised C code for alloca())
>>     declare
>>       My_String : String_Access := Alloca(String(1..8));
>>     begin
>>       ...
>>       Put_Line(My_String.all);
>> 
>>     -- Real Ada here
>>     declare
>>        My_String : String(1..8);
>>     begin
>>        ...
>>        Put_Line(My_String);
>> 
>> Apart from getting a pointer from alloca(), I don't see any
>> advantage. Both forms allocate from the stack frame.
>> 
>>>    declare
>>>       Name: String := "";
>>>       pragma Extensible_Object(Name);
>>>    begin
>>>       ...
>>>       Name := Name & ':'; -- changes its size
>>>       ...
>>> 
>>> It's an idea.
>> 
>> This is taking the alloca() idea further than I think it
>> goes. I could be wrong here, but can you realloc() an
>> alloca() region?  If so, that is something that Ada does
>> in fact lack (including a realloc() in general, which I
>> pine for when growing arrays).
>> 
>> Warren.
> 
> Hmmm... Perhaps we could do that, and even more, by using Tasks and/or
> Protected Objects. After all, on a platform with stack frames, doesn't
> instantiation of a new task initialize a new stack frame? A Task
> Storage_Pool would also be a Pool of stack frames? 
> I'll have to go look it up, but if there is a way to declare Tasks or
> Protected Objects as Controlled or Limited_Controlled within a
> Storage_Pool(or perhaps in the general storage_pool), then it might be
> possible.

They are limited but not controlled. When you allocate a task or protected
object using "new" you can put it in a storage pool you want. Though this
would not affect the task's stack.

> Another possibility would be duplicating exactly the current task in
> another task with a larger stack frame, switching control to the new task,
> and killing off the old one, or keeping it around if the current new task
> shrinks to the point where it's larger stack frame is no longer needed.

Ooch. The difference between stack and heap is exactly that stack objects
need not to be reallocated. So it seems that what you want is just a heap.
The only way a stack could be used for resizable objects is when the object
to resize is on the stack top. Let you have implemented that. How would you
deal with two objects:

declare
   O1 : Resizable;
   O2 : Resizable;
begin
   Enlarge (O1);
   Enlarge (O2);
   Enlarge (O1);
end;

Basically to cope with that you will need a pool of stacks per task. Each
object declaration in one block goes to a separate stack. Nice? Nope,
because of:

declare
   O1 : Resizable;
   declare
      O2 : Resizable;
   begin
      Enlarge (O1);
      Enlarge (O2);
      Enlarge (O1);
   end;
end;

In the end an implementation based on smart pointers to heap allocated
objects will beat your stacks. The only problem with smart pointers in Ada
is that controlled objects required for them are too heavy-weighted. So if
you want to patch Ada, better add proper constructors / destructors /
assignment (for user-defined access types) there!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de