Re: Which is right here - GNAT or OA ?

[Robert Dewar <robert_dewar@my-deja.com>]

In article <928174549.336.98@news.remarQ.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
> As a matter of fact this is amazingly simple.

No, doing this without adding unacceptable overhead is not
simple, and in fact is simply not practical.

> If I can do this
> check at a run time myself  why RTS can not do the same ?

Because the cost is too high

> The cost of this is one  additional  hidden field in the type
> representation which  is set to needed value during object
> creation.

Yes, and that cost is much too high, for example, if you have
a simple linked list type, you could be talking about adding
a storage overhead of 20-25%.

Surely you must realize your method is completely obvious! The
fact that the RM makes this situation erroneous is an explicit
indication that the designers of the language have considered
your solution and rejected it as introducing excessive overhead.

The design is very sensitive to avoiding unnecessary storage
use. FOr example, the confusing difference between:

   A : aliased constant String (1 .. 80) := " 80 chars ...";
   A : aliased constant String           := " 80 chars ...";

is solely to save the 8 bytes that would otherwise be required
for the bounds in the first case.





>  Soon I demonstrate this simple technique in set of "talking"
examples that
> are almost ready to be posted to AdaPower.
> The same thing could be done by the compiler itself.  There
even will be no
> need to have additional public run time attributes.
> Compiler or allocator sets  this field during object creation
and  RTS can
> check this field and do what needed depending on value of this
field upon
> object deallocation request. This could be very handy.
>
> >
> >Another but related thing surprises me---it's AARM
12.5.4(4.a):
> >
> >| If no _modifier applies to the formal, then the actual type
may be
> >| either a pool-specific or a general access-to-variable
type.
> >
> >I can't imagine any reason why an access-to-variable type
should be
> >allowed as an actual parameter for a formal access type
without an
> >`all' modifier.  If this was changed, an access-to-variable
would not be
> >allowed as a parameter in an instantiation of
Ada.Unchecked_Deallocation,
> >which seems quite reasonable to me.  (I don't claim that the
language
> >definition inadequate here, I simply can't make sense out of
it, which
> >is very likely my own fault. ;)
>
> Yes, very interesting,  I agree, it does not go all along the
line with Ada
> strong type checking.
> In some circumstances it may cause the same result that was
demonstrated in
> my small demo.
>
> Regards,
>
> Vladimir Olensky
>
>


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.