Re: RE: Ada 0y wish list:

Re: RE: Ada 0y wish list:

[Ted Dennison]

In article <mailman.982264694.19416.comp.lang.ada@ada.eu.org>, Beard, Frank
says...
>
>I disagree.  If the compiler treated the deferred type
>as a "by
reference" type then there wouldn't be a problem.
>It would be similar to an
access type without the requirement
>of allocation/deallocation, null checks,
etc.
>
>When a variable of type B is declared, the compiler will
>always pass it
by reference (by address), which is the
>equivalent of passing an access
type.

But passing parameters isn't the only issue. You also have to generate
code for
allocating stack space for objects of that type. In extreme cases, you
might
even need to create an array type or do something else relatively static
based
on the type's 'size. How are you going to do that without needing that
code to
be regenerated whenever the source file containing the definition of
the
object's size is recompiled?


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

RE: RE: Ada 0y wish list:

[Beard, Frank]

What I had envisioned is that it would work very similar
to an access type.  However stack space is controlled for
an access type would be the same way to control the stack
space for the deferred by reference type.

As for the size, it would deviate slightly from access types,
in that to get the size of an access type it is X.all'size.
For the deferred type it would still be X'size, because the
compiler would know that it's a deferred type and do the
X.all'size equivalent, transparent to the user.

The Alsys compiler on the LynxOs documented that if a
subprograms variable's size was larger than 2048 is would
allocate it from the heap; otherwise, it would allocate
it from the stack.  Alsys made that decision based on the
size, so why can't that decision be made based on the type.
Then there would never be a stack issue.  Again, it would
be similar to an access type.

If the unit is recompiled, then the executable has to be
rebound.  Since the internal variable tables have been
updated, the bind (link) should resolve the new sizes.

Frank

-----Original Message-----
From: Ted Dennison [mailto:dennison@telepath.com]
Sent: Thursday, February 15, 2001 3:04 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: RE: Ada 0y wish list: 


But passing parameters isn't the only issue. You also have to generate
code for
allocating stack space for objects of that type. In extreme cases, you
might
even need to create an array type or do something else relatively static
based
on the type's 'size. How are you going to do that without needing that
code to
be regenerated whenever the source file containing the definition of
the
object's size is recompiled?


---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

_______________________________________________
comp.lang.ada mailing list
comp.lang.ada@ada.eu.org
http://ada.eu.org/mailman/listinfo/comp.lang.ada

Re: RE: RE: Ada 0y wish list:

[Ted Dennison]

In article <mailman.982270874.22619.comp.lang.ada@ada.eu.org>, Beard, Frank
says...
>
>What I had envisioned is that it would work very similar
>to an access type.  However stack space is controlled for
>an access type would be the same way to control the stack
>space for the deferred by reference type.
>
>As for the size, it would deviate slightly from access types,
>in that to get the size of an access type it is X.all'size.
>For the deferred type it would still be X'size, because the
>compiler would know that it's a deferred type and do the
>X.all'size equivalent, transparent to the user.

You seem to be operating on the old maxim that "any problem can be solved by
adding an additional level of indirection." However, I'm not sure this is one of
those cases. Whether its implemented as a stack object or a heap object does not
change the fact that the referencing code is going to have to be generated to go
out and get X bytes for the object from somewhere, and that code will have to be
recompiled whenver you change the source file that contains the calculation of
X.

Of course adherents to the indiection priciple I mentioned above would just
point out that X itself could be accessed as a variable instead of a constant,
even though it won't ever change within the type's scope. Yuk. 

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com