From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,HEADER_SPAM autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fc772,b30bd69fa8f63cb2 X-Google-Attributes: gidfc772,public X-Google-Thread: 103376,b30bd69fa8f63cb2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-06-14 17:38:00 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!uwm.edu!rpi!not-for-mail From: "Robert I. Eachus" Newsgroups: comp.lang.ada,comp.lang.c++.moderated Subject: Re: C bug of the day Date: 14 Jun 2003 20:40:10 -0400 Organization: AT&T Broadband Sender: cppmods@netlab.cs.rpi.edu Message-ID: <3EEB5633.70107@attbi.com> References: <1054751321.434656@master.nyc.kbcfp.com> <20619edc.0306121052.643eb4ec@posting.google.com> NNTP-Posting-Host: netlab.cs.rpi.edu X-Original-Date: Sat, 14 Jun 2003 17:07:24 GMT X-Submission-Address: c++-submit@netlab.cs.rpi.edu X-Auth: PGPMoose V1.1 PGP comp.lang.c++.moderated iQBVAwUAPuvAVEHMCo9UcraBAQGqJwH/eYvwWHN1ne65ECIxQjbgn49Kpl4iTy/l atzrlC+M2SIaY2ttAbFgV5lzprWVxaa97R0EsLkA94OWtR5iPn4NZQ== =jjKQ Xref: archiver1.google.com comp.lang.ada:39186 comp.lang.c++.moderated:68365 Date: 2003-06-14T20:40:10-04:00 List-Id: Mike Silva wrote: > kanze@gabi-soft.fr wrote in message news:... > > > > 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! ]