comp.lang.ada
 help / color / mirror / Atom feed
From: Martin Krischik <krischik@users.sourceforge.net>
Subject: Re: Dynamich Dispatching...
Date: Mon, 04 Oct 2004 10:22:21 +0200
Date: 2004-10-04T10:22:21+02:00	[thread overview]
Message-ID: <1265664.39nQz63IPR@linux1.krischik.com> (raw)
In-Reply-To: sa4pt3z76hl.fsf@snoopy.apana.org.au

Brian May wrote:

>>>>>> "Martin" == Martin Krischik <krischik@users.sourceforge.net> writes:
> 
>     Martin> Avoid "access all" unless you need it. The compiler need
>     Martin> to do more checking when using "access all".
> 
> Some references recommend using "all" - not sure why.

"access all" can hold pointers to all sorts of elements. They may be on the
stack or inside any user defined heap. Therfore they are far more flexible.
However - all flexibility brings the change for error. For example I can
think of at least 3 times as many things which can go wrong on an
Unchecked_Deallocation for an "access all" then for an simple "access".

Want to know?

For access:

Deallocating memory still in use.

For access all:

Deallocating memory still in use.
Deallocating memory from the wrong storrage pool.
Deallocating stack memory.

See that's three times.

> What extra 
> checking does it require? My references say when to use it, but never
> say when not to use it

My 2 cent: "access all" should not be used when user defined storrage pools
are used as well. 

> or why it shouldn't be used if not required. 

access is allways allocated on one specific heap - So especially for library
level access no live time check is needed. Ada prevents dangling pointer by
making livetime checks. The classical C mistake

int*
f ()
  {
   auto int Retval;

   return &Retval;
   }

will cause an error in Ada - since Retval goes out of scope at function end.
Most of the livetime checks are done at compile time - however there are a
few to be done at run time. 

Important here is that for a named "access" - that is "type X is access Y"
all livetime checks can be done at compile time. 

>     >> procedure Main is
>     >> procedure Call_Dynamic(Object_Ptr: Objects.Object_Ptr) is
> 
>     Martin> procedure Call_Dynamic(Object: Objects.Object'Class) is
> 
>     >> begin
>     >> Objects.Draw(Object_Ptr.all);
> 
>     Martin> Objects.Draw(Object);
> 
>     >> end Call_Dynamic;
>     >> C2 : Circles.Circle;
> 
>     Martin> C3 : Object_Ptr := new Circles.Circle'Class'(C2);
> 
>     >> begin
>     >> C2 := Circles.Constructor.Create("Circle1",50);
>     >> Call_Dynamic (new Circles.Circle'(C2));
> 
>     Martin> Call_Dynamic (C3);
> 
> I think you meant "Call_Dynamic(C2)" here. You can't pass an access
> type here...

No I meant "Call_Dynamic(C3.all)". Of course you might not need a pointer at
all. An Ada one can often use 'Class where in C++ a pointer or reference is
needed.

When I was 2 to 3 month into Ada I reorganised my Ada programs removing 
more then 80% of all pointers used until then.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com




  reply	other threads:[~2004-10-04  8:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-02 15:39 Dynamich Dispatching Rick Santa-Cruz
2004-10-03 17:11 ` Martin Krischik
2004-10-03 22:59   ` Brian May
2004-10-04  8:22     ` Martin Krischik [this message]
2004-10-03 18:56 ` Ludovic Brenta
2004-10-04  4:45   ` Jeffrey Carter
2004-10-04 21:01     ` Ludovic Brenta
2004-10-05  0:32       ` Jeffrey Carter
2004-10-04  8:02 ` Dmitry A. Kazakov
2004-10-04 11:02   ` Brian May
2004-10-04 12:50     ` Dmitry A. Kazakov
2004-10-15 18:27       ` Matthew Heaney
2004-10-16 19:25         ` Dmitry A. Kazakov
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox