Re: How to get Ada to 'cross the chasm'?

["Randy Brukardt" <randy@rrsoftware.com>]

"Paul Rubin" <no.email@nospam.invalid> wrote in message
news:87d0y97lda.fsf@nightsong.com...
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> One reason is that when a function evaluates an expression that
>> creates an object of a large, dynamic size (eg. an array expression)
>> on the secondary stack, this object can be returned /in situ/ as the
>> function's return value, without being copied.
>
> Ok, but that pattern is so common that allocating the space in the
> primary stack before calling the function is a standard optimization
> that every serious C++ compiler knows how to do.  Then the function
> writes the result into the primary stack and the caller can still use it
> after the function returns.  Could Ada not do it the same way?

It usually does when the size of the object is known at compile time. The
secondary stack is mainly used for returning object whose size is not known
at compile-time. (Note: I don't know the details of the GNAT
implementation.) The classic example is a function returning a string:

   function My_Image (Val : in Integer) return String;

Here, the size of the string returned isn't known until the function figures
it out; there's no way for the caller to know that (as it doesn't
necessarily know anything about the body).

Janus/Ada returns such objects on the heap rather than horsing around with a
second stack. (When I get a Round Tuit, I'm going to move static-sized
objects to essentially be parameters to the function, one of zillion
projects that I need to do someday soon.) It keeps track of them and frees
them up when they're no longer needed (using a mechanism very similar to
finalization). The cost isn't much different than the secondary stack, and
you can't really analyze either very well.

            Randy.


                     Randy.