Re: C bug of the day

["Robert I. Eachus" <rieachus@attbi.com>]

Mike Silva wrote:
> kanze@gabi-soft.fr wrote in message news:<d6652001.0306120418.37a97d1c@posting.google.com>...
>  >
>  > One point where I'm pretty sure Ada 83 didn't have the right default
>  > (although they may have fixed it in Ada 95): garbage collection.  While
>  > there are places where it is necessary to turn garbage collection off
>  > (which seriously limits the use of a language in which you cannot have
>  > untraced pointers, which the garbage collector cannot see), the safe
>  > option is obviously to have it on by default, no?
> 
> I've read that Ada customers don't ask for garbage collection, because
> in typical Ada applications (safety-critical, hard realtime embedded)
> dynamic allocation is simply not acceptable.

Hmmm...  I'd rather say that for 99% of what garbage collection is 
needed for in other languages, in Ada it is easy enough to avoid 
creating the garbage in the first place.  Most objects are created on 
the stack instead of the heap, so no garbage collection is required. 
For strings, one of the major causes of garbage in C and C++, the 
package Ada.Strings.Unbounded provides an arbitrary length string type 
with the requirement in RM A.4.5(88): "No storage associated with an 
Unbounded_String object shall be lost upon assignment or scope exit."

If you really need true garbage collection, there is also the ability to 
define a storage pool (see RM13.11 Storage Management) which has full 
garbage collection.  I think in Ada0Y there will probably be three 
packages which provide non-default storage pools with mark-release and 
full garbage collection.  Using them will require withing the 
appropriate package (and possibly instantiating a generic or calling a 
procedure to set the pool size depending on the approach selected.

 From then on, all you need to do to get garbage collection for a type 
is add an attribute_definition_clause for the access type:

for T'Storage_Pool use Garbage_Collection;

Why three packages?  There is a major advantage to having all the 
objects in a collection the same size.  So there will probably be two 
garbage collection storage pools, one where the size of all objects 
allocated from the pool is set when the pool is created, and one where 
the size of an object is set at allocation time.

As you can see, storage pools in Ada allow the programmer to mix many 
types of storage management, and not have the actual code which creates 
(and/or destroys) objects cluttered up with storage management code. 
This is, as far as I am concerned, a wonderful feature of Ada.  You can, 
for example have full garbage collection for some complex type, while in 
time critical sections of code you can avoid triggering garbage 
collection.  Remember garbage collection is associated with an access 
type, and not with the type of the actual data object.  So you can have

function My_Device_Driver(...) return Data;

where no garbage collection or storage management can occur, and call it 
in an allocator:

Some_Pointer := new Data'(My_Device_Driver(...));

Which may trigger garbage collection, but after the object value has 
been created and outside any time critical regions of code. You can 
even, if you have the need, have multiple access types with different 
storage management policies for the same data type. ;-)

So as far as I am concerned, in Ada(95) all the garbage collection you 
may ever need is "in there."  And the defaults (no garbage collection, 
heap management for Ada.Strings.Unbounded.) are correct.


      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]