comp.lang.ada
 help / color / mirror / Atom feed
From: Matthias Kretschmer <McCratch@gmx.net>
Subject: Re: Universities in the US - Garbage Collector for GNAT?
Date: Wed, 16 May 2001 22:12:00 +0200
Date: 2001-05-16T22:12:00+02:00	[thread overview]
Message-ID: <20010516221200.4247be5f.McCratch@gmx.net> (raw)
In-Reply-To: 9dukqo$mmh$1@nh.pace.co.uk

On Wed, 16 May 2001 15:35:50 -0400
"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote:

> Well, there are certainly "evil" things you can do in Ada. It's never been
> the least bit hard to write bad code in any language. Just for instance: Ada
> gives you lots of direct access to the machine (machine code & addresses),
> representations of data, multi-tasking, etc. Any of these things can be very
> powerful if used judiciously. Its very easy to imagine how with multiple
> tasks running in parallel and being used by someone unfamiliar with tasking
> how it could easily make a program *very* difficult to maintain or debug!
> (Just think of shared access by multiple threads to some resource.)

Of course it is always up to the programmer, but most projects aren't done by one programmer and if there are tricks they are used I would say - maybe not all, but they are used. The representation of data is just something you use to give the compiler a hint how to handle it, instructing the compiler to use specific memory-addresses is a "feature" you need in some projects and there it has to be used carefully, in other projects it should be used (so not all addresses should be supported by the OS in a modern multitasking/multiprocessing environment). In my opion you can always do evil things with threads. I should change my comment to: You can do more evil things in language one than in language two. - but this depends on what is considered evil.

> 
> As for Garbage Collection: Observations by one or more compiler vendors seem
> to indicate that while occasionally people make noise about it, nobody seems
> to want it bad enough to make it a priority. Additionally, Ada typically
> uses far less dynamically allocated memory and far fewer pointers than what
> programmers commonly use in C/C++. Since in most garden variety programs the
> bulk of allocation is static or off the stack, it is less of an issue.
> Thirdly, lots of programmers when building their own dynamic data
> structures, take advantage of Unchecked_Deallocation and Finalization to
> clean up memory that might be hanging around, so garbage collection seems a
> lot less necessary. (Assuming that for your implementation,
> Unchecked_Deallocation ends up returning the memory to the system - it may
> not...) Generally, it just doesn't seem important enough to create a strong
> constituency.
> 

Well in some projects it could be usefull and in others you don't need it, but as long as there exists the possibility and usage I won't miss it. :-) - Grown up with Borland Pascal it seems totally natural to deallocate memory for yourself, but sometimes I don't want to think of memory ... - I hoped someone got gnat working with a GC.



  reply	other threads:[~2001-05-16 20:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-15 14:46 Universities in the US Faisal Halim
2001-05-15 15:22 ` Barry Margolin
2001-05-15 15:43 ` Ted Dennison
2001-05-15 16:04   ` Wade Humeniuk
2001-05-15 17:50     ` Kevin Rigotti
2001-05-15 18:33       ` Marin David Condic
2001-05-15 18:52         ` James Hague
2001-05-15 19:51           ` Marin David Condic
2001-05-15 21:24         ` Lieven Marchand
2001-05-16 17:00           ` Marin David Condic
2001-05-16 19:01             ` Universities in the US - Garbage Collector for GNAT? Matthias Kretschmer
2001-05-16 19:35               ` Marin David Condic
2001-05-16 20:12                 ` Matthias Kretschmer [this message]
2001-05-16 14:11         ` Universities in the US Evan Prodromou
2001-05-15 19:29     ` Ted Dennison
2001-05-16 22:19     ` David Thornley
2001-05-15 16:12   ` Gary Scott
2001-05-15 20:10 ` Eric de Groot
replies disabled

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