Re: C bug of the day

[kanze@gabi-soft.fr]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5527 bytes --]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:<3EEB5633.70107@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.

I'm sure that there are applications where garbage collection is not
acceptable.  They may even be the majority of Ada applications.  But the
fact remains that garbage collection is the "safe" option, and so
according to the premise that the defaults should always be the "safe"
options, garbage collection should be on by default.

> 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."

Which other languages?  What you've just said above describes C++
perfectly.

> 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.

So you have additional standard library support for special cases.  You
can do the same in C++ (I do, from time to time), but you have to do it
by hand.  Generally speaking, for the types of applications I've worked
on recently, it hasn't been appropriate, but for some of the types I've
worked on in the distant past, it would have been.

> 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.

This is all nice and fine if you need it.  The advantage of garbage
collection is that usually, it just does the right thing (or at least,
something perfectly acceptable) without any programmer intervention.
(For memory management, of course.  Lifetime of object issues still
cannot be completely ignored.)

> 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. ;-)

The garbage collections I've heard about for C++ don't trigger at random
times either.  They will trigger when you attempt to allocate, or you
can explicity trigger them, but they won't trigger just for the fun of
it.

> 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.

According to what criteria?  The default may be the most useful for the
application domains where Ada is used, but it isn't the safest.

--
James Kanze             GABI Software             mailto:kanze@gabi-soft.fr
Conseils en informatique orient�e objet/
                           Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, T�l. : +33 (0)1 30 23 45 16

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]