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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,345a8b767542016e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-03-15 01:37:04 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!sunqbc.risq.qc.ca!newsfeed.mathworks.com!btnet-peer0!btnet!dispose.news.demon.net!news.demon.co.uk!demon!pipehawk.demon.co.uk!not-for-mail From: john.mccabe@emrad.ns.com (John McCabe) Newsgroups: comp.lang.ada Subject: Re: memory leakages with Ada? Date: Fri, 15 Mar 2002 09:37:03 GMT Organization: Emrad Ltd Message-ID: <3c91bfa3.1987537@news.demon.co.uk> References: <3c90af1e@news.starhub.net.sg> NNTP-Posting-Host: pipehawk.demon.co.uk X-NNTP-Posting-Host: pipehawk.demon.co.uk:158.152.226.81 X-Trace: news.demon.co.uk 1016184968 nnrp-08:15326 NO-IDENT pipehawk.demon.co.uk:158.152.226.81 X-Complaints-To: abuse@demon.net X-Newsreader: Forte Free Agent 1.21/32.243 Xref: archiver1.google.com comp.lang.ada:21269 Date: 2002-03-15T09:37:03+00:00 List-Id: On Thu, 14 Mar 2002 15:12:21 -0500, "Marin David Condic" wrote: >In comparing Ada to C on this there are two observations: One is that Ada >provides a different model for dynamic allocation than does C that includes, >among other things, a lot more checks/safety features to minimize the >possibility of lost memory. (Still, the standard doesn't require garbage >collection so you can still leak memory if you mess things up.) It isn't >impossible to leak memory in Ada - just less likely. One of the things I've found recently, since starting to use C++ more, is that Ada.UncheckedDeallocation is so much nicer than 'delete' as it returns you a nice, null pointer! 'delete' in C++ appears to remove the allocated block, but leave your pointer pointing to where it used to be! >The other thing is that stylistically, Ada tends to do things off of the >stack or global memory rather than require lots of dynamic allocation. Short >of building your own linked data structures, you generally almost *never* >create things via dynamic allocation. (Constrast this with C where you >routinely do dynamic allocation of strings or structs and routinely manage >pointers to all sorts of things.) If you find you are constantly dynamically >allocating things in your Ada programs, you are probably not doing it The >Ada Way (trying to translate C into Ada?) and need to rethink what you're >doing. I'm not convinced this comment is 100% valid, from having worked on large scale Object-Oriented Ada projects over the last 3 years or so where there has been significant (if not huge) amounts of dynamic allocation. It is at least partially true in that you can often restructure your code to avoid dynamic allocation, but...