* memory leakages with Ada? @ 2002-03-14 14:07 Calvin Ow 2002-03-14 14:31 ` Larry Kilgallen ` (4 more replies) 0 siblings, 5 replies; 79+ messages in thread From: Calvin Ow @ 2002-03-14 14:07 UTC (permalink / raw) Hi, Has Ada got any memory leakage problems like that of C? Especially with the use of Pragma calls to C? ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-14 14:07 memory leakages with Ada? Calvin Ow @ 2002-03-14 14:31 ` Larry Kilgallen 2002-03-14 20:42 ` Nick Roberts 2002-03-14 21:07 ` Anh_Vo 2002-03-14 20:12 ` Marin David Condic ` (3 subsequent siblings) 4 siblings, 2 replies; 79+ messages in thread From: Larry Kilgallen @ 2002-03-14 14:31 UTC (permalink / raw) In article <3c90af1e@news.starhub.net.sg>, "Calvin Ow" <calvow@cyberway.com.sg> writes: > Has Ada got any memory leakage problems like that of C? Ada95 has several additional capabilites to guard against memory leaks. It is possible to bypass most checks in Ada, so one could encounter just as much trouble in Ada if one attempted to transliterate a C program into Ada while retaining every aspect of the C design. > Especially with the use of Pragma calls to C? If you call from Ada to C, the portion that is written in C is fully empowered to leak all the memory it wants :-) Thus the question of memory leaks when doing that boils down to an issue of whether the C code is well written. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-14 14:31 ` Larry Kilgallen @ 2002-03-14 20:42 ` Nick Roberts 2002-03-14 21:11 ` Larry Kilgallen 2002-03-14 21:07 ` Anh_Vo 1 sibling, 1 reply; 79+ messages in thread From: Nick Roberts @ 2002-03-14 20:42 UTC (permalink / raw) Larry Kilgallen wrote: >In article <3c90af1e@news.starhub.net.sg>, "Calvin Ow" <calvow@cyberway.com.sg> writes: > >>Has Ada got any memory leakage problems like that of C? >> > >Ada95 has several additional capabilities to guard against memory leaks. > Someone correct me if I'm wrong, but I think it would be more correct to put it this way: the Ada language makes provision for an implementation to provide garbage collection. If an Ada program is compiled/executed under an implementation that provides garbage collection, then this counts as a 'capability to guard against memory leaks'. If it provides _full_ garbage collection, this will normally provide complete protection against memory leaks. However, all this is slightly academic, as (I am given to believe) there are no Ada implementations that provide garbage collection (apart from the ones which target the JVM, which is a somewhat different billie-can of anchovies anyway). Without GC, dynamic allocation will cause memory leakage (in the generally accepted meaning) unless: unused memory is freed explicitly (by the use of Unchecked_Deallocation); or, the algorithm uses (or tends to use) all or most dynamically allocated objects up until the end of the scope of the relevant access type's declaration (usually the end of the program's execution). This is pretty much the same situation as with C. Of course, memory leakage can also be caused, in any programming language, by: faults in the compiler; programs doing low-level things, and getting it wrong. Typically, utility libraries which provide 'containers' will need to do a lot of explicit freeing of memory; a bug can easily cause memory leakage. >It is possible to bypass most checks in Ada, so one could encounter >just as much trouble in Ada if one attempted to transliterate a C >program into Ada while retaining every aspect of the C design. > >>Especially with the use of Pragma calls to C? >> > >If you call from Ada to C, the portion that is written in C is >fully empowered to leak all the memory it wants :-) Thus the >question of memory leaks when doing that boils down to an >issue of whether the C code is well written. > Note that there are plenty of other kinds of problems associated with memory management that Ada (both the standard language and typical implementations) provides good protection against, and C does not. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-14 20:42 ` Nick Roberts @ 2002-03-14 21:11 ` Larry Kilgallen 0 siblings, 0 replies; 79+ messages in thread From: Larry Kilgallen @ 2002-03-14 21:11 UTC (permalink / raw) In article <3C910B50.2030208@callnetuk.com>, Nick Roberts <nickroberts@callnetuk.com> writes: > > > Larry Kilgallen wrote: > >>In article <3c90af1e@news.starhub.net.sg>, "Calvin Ow" <calvow@cyberway.com.sg> writes: >> >>>Has Ada got any memory leakage problems like that of C? >>> >> >>Ada95 has several additional capabilities to guard against memory leaks. >> > > Someone correct me if I'm wrong, but I think it would be more correct to > put it this way: the Ada language makes provision for an implementation > to provide garbage collection. That would be nice if one were talking about garbage collection, but I wasn't. I was talking about user defined initialization, assignment and finalization of controlled types. Accessibility levels for access types might also be relevant in constraining unwarranted "creativity". ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-14 14:31 ` Larry Kilgallen 2002-03-14 20:42 ` Nick Roberts @ 2002-03-14 21:07 ` Anh_Vo 1 sibling, 0 replies; 79+ messages in thread From: Anh_Vo @ 2002-03-14 21:07 UTC (permalink / raw) For Ada95 I have developped a simple utility package to detect memory leaks. Most of all, it can pinpoint where the leaks occur. Thus, memory leaks can be fixed. The source code is available on www.adapower.com/lang/mempool2.html. In addition, I do have the latest version. I can email to you if requested. By the way, GNAT-3.14p has package called GNAT.Debug_Pools. It can be used to detect memory leaks also. Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<pWLUJHzQF0ha@eisner.encompasserve.org>... > In article <3c90af1e@news.starhub.net.sg>, "Calvin Ow" <calvow@cyberway.com.sg> writes: > > > Has Ada got any memory leakage problems like that of C? > > Ada95 has several additional capabilites to guard against memory leaks. > It is possible to bypass most checks in Ada, so one could encounter > just as much trouble in Ada if one attempted to transliterate a C > program into Ada while retaining every aspect of the C design. > > > Especially with the use of Pragma calls to C? > > If you call from Ada to C, the portion that is written in C is > fully empowered to leak all the memory it wants :-) Thus the > question of memory leaks when doing that boils down to an > issue of whether the C code is well written. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-14 14:07 memory leakages with Ada? Calvin Ow 2002-03-14 14:31 ` Larry Kilgallen @ 2002-03-14 20:12 ` Marin David Condic 2002-03-15 9:37 ` John McCabe 2002-03-15 17:41 ` Kevin Cline 2002-03-14 23:14 ` Kevin Cline ` (2 subsequent siblings) 4 siblings, 2 replies; 79+ messages in thread From: Marin David Condic @ 2002-03-14 20:12 UTC (permalink / raw) 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. 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. As a result, memory leaks are far less frequent in Ada programs, so you'll save lots of nasty debugging time. As for interfacing to C - the C code is free to leak all the memory it wants so you get no guarantees. It may also depend on the compiler(s) in question. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Calvin Ow" <calvow@cyberway.com.sg> wrote in message news:3c90af1e@news.starhub.net.sg... > Hi, > Has Ada got any memory leakage problems like that of C? > Especially with the use of Pragma calls to C? > > ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-14 20:12 ` Marin David Condic @ 2002-03-15 9:37 ` John McCabe 2002-03-15 12:55 ` Pat Rogers ` (2 more replies) 2002-03-15 17:41 ` Kevin Cline 1 sibling, 3 replies; 79+ messages in thread From: John McCabe @ 2002-03-15 9:37 UTC (permalink / raw) On Thu, 14 Mar 2002 15:12:21 -0500, "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> 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... ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 9:37 ` John McCabe @ 2002-03-15 12:55 ` Pat Rogers 2002-03-16 4:36 ` Will 2002-03-16 9:13 ` DPH 2002-03-15 14:20 ` Marin David Condic 2002-03-15 16:00 ` Hyman Rosen 2 siblings, 2 replies; 79+ messages in thread From: Pat Rogers @ 2002-03-15 12:55 UTC (permalink / raw) "John McCabe" <john.mccabe@emrad.ns.com> wrote in message news:3c91bfa3.1987537@news.demon.co.uk... > On Thu, 14 Mar 2002 15:12:21 -0500, "Marin David Condic" > <dont.bother.mcondic.auntie.spam@[acm.org> 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! Although there are several things I really like about C++, one of the things that I find shocking is that the programmer must remember to use a very slightly different syntax when calling delete on an allocated array, and that the other syntax will also compile and run -- and at the very least leak. (I understand the reason for this, don't bother to explain why; it still stinks!) That isn't the only such example, of course, but one that I find amazing. For example, the following is perfectly legal and wrong : char* p = new char[n]; delete p; I have to remember to say: delete[] p; I'm not saying Ada is perfect, so let's nobody start the language wars please, but Ada is clearly better in this regard. --- Patrick Rogers Consulting and Training in: http://www.classwide.com Real-Time/OO Languages progers@classwide.com Hard Deadline Schedulability Analysis (281)648-3165 Software Fault Tolerance ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 12:55 ` Pat Rogers @ 2002-03-16 4:36 ` Will 2002-03-16 4:53 ` Pat Rogers 2002-03-16 12:21 ` Larry Kilgallen 2002-03-16 9:13 ` DPH 1 sibling, 2 replies; 79+ messages in thread From: Will @ 2002-03-16 4:36 UTC (permalink / raw) "Pat Rogers" <progers@classwide.com> wrote in message news:<Xamk8.66050$> > Although there are several things I really like about C++, one of the things > that I find shocking is that the programmer must remember to use a very slightly > different syntax when calling delete on an allocated array, and that the other > syntax will also compile and run -- and at the very least leak. (I understand > the reason for this, don't bother to explain why; it still stinks!) That isn't > the only such example, of course, but one that I find amazing. > > For example, the following is perfectly legal and wrong : > > char* p = new char[n]; > delete p; > > I have to remember to say: > > delete[] p; Well, I remember Mr Stroustrup saying something to the effect that this is to ease the job of the compiler writer. Looks to me more like a marketing decision than a technical one. > > > I'm not saying Ada is perfect, so let's nobody start the language wars please, > but Ada is clearly better in this regard. If I am paranoid about leaks, I would have used LISP :) ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-16 4:36 ` Will @ 2002-03-16 4:53 ` Pat Rogers 2002-03-16 12:21 ` Larry Kilgallen 1 sibling, 0 replies; 79+ messages in thread From: Pat Rogers @ 2002-03-16 4:53 UTC (permalink / raw) "Will" <wv9557@yahoo.com> wrote in message news:4a885870.0203152036.37c68e91@posting.google.com... > "Pat Rogers" <progers@classwide.com> wrote in message news:<Xamk8.66050$> > > Although there are several things I really like about C++, one of the things > > that I find shocking is that the programmer must remember to use a very slightly > > different syntax when calling delete on an allocated array, and that the other > > syntax will also compile and run -- and at the very least leak. (I understand > > the reason for this, don't bother to explain why; it still stinks!) That isn't > > the only such example, of course, but one that I find amazing. > > > > For example, the following is perfectly legal and wrong : > > > > char* p = new char[n]; > > delete p; > > > > I have to remember to say: > > > > delete[] p; > > Well, I remember Mr Stroustrup saying something to the effect that this is to > ease the job of the compiler writer. Looks to me more like a marketing decision > than a technical one. The reason is in fact technical. C++ cannot distinguish a single item from an array of them, so we have to tell the poor compiler which. Imagine what happens if p really does *not* designate an array... :-) > > I'm not saying Ada is perfect, so let's nobody start the language wars please, > > but Ada is clearly better in this regard. > > If I am paranoid about leaks, I would have used LISP :) :-) ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-16 4:36 ` Will 2002-03-16 4:53 ` Pat Rogers @ 2002-03-16 12:21 ` Larry Kilgallen 1 sibling, 0 replies; 79+ messages in thread From: Larry Kilgallen @ 2002-03-16 12:21 UTC (permalink / raw) In article <4a885870.0203152036.37c68e91@posting.google.com>, wv9557@yahoo.com (Will) writes: > Well, I remember Mr Stroustrup saying something to the effect that this is to > ease the job of the compiler writer. Looks to me more like a marketing decision > than a technical one. I recall reading that several proposed Ada95 features did not make the cut because existing vendors felt it would be too hard support with their implementations. Certainly at least one vendor dropped out because of the degree of change from Ada83. Thus Ada also has such balancing acts to deal with, but in that sense it just copies the real world. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 12:55 ` Pat Rogers 2002-03-16 4:36 ` Will @ 2002-03-16 9:13 ` DPH 2002-03-16 14:38 ` Pat Rogers 2002-03-16 20:18 ` Robert A Duff 1 sibling, 2 replies; 79+ messages in thread From: DPH @ 2002-03-16 9:13 UTC (permalink / raw) On Fri, 15 Mar 2002 12:55:19 GMT, "Pat Rogers" <progers@classwide.com> wrote: >"John McCabe" <john.mccabe@emrad.ns.com> wrote in message >news:3c91bfa3.1987537@news.demon.co.uk... >> On Thu, 14 Mar 2002 15:12:21 -0500, "Marin David Condic" >> <dont.bother.mcondic.auntie.spam@[acm.org> 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! > >Although there are several things I really like about C++, one of the things >that I find shocking is that the programmer must remember to use a very slightly >different syntax when calling delete on an allocated array, and that the other >syntax will also compile and run -- and at the very least leak. (I understand >the reason for this, don't bother to explain why; it still stinks!) That isn't >the only such example, of course, but one that I find amazing. > >For example, the following is perfectly legal and wrong : > >char* p = new char[n]; >delete p; > >I have to remember to say: > >delete[] p; No you don't... you just write it with Borland C++ Builder 5 or better with CodeGuard turned on, and CodeGuard will complain about it all over the place. Dave Head > > >I'm not saying Ada is perfect, so let's nobody start the language wars please, >but Ada is clearly better in this regard. > >--- >Patrick Rogers Consulting and Training in: >http://www.classwide.com Real-Time/OO Languages >progers@classwide.com Hard Deadline Schedulability Analysis >(281)648-3165 Software Fault Tolerance > > ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-16 9:13 ` DPH @ 2002-03-16 14:38 ` Pat Rogers 2002-03-16 14:56 ` DPH 2002-03-16 20:18 ` Robert A Duff 1 sibling, 1 reply; 79+ messages in thread From: Pat Rogers @ 2002-03-16 14:38 UTC (permalink / raw) "DPH" <rally2xs@compuserve.com> wrote in message news:s3369uo70srjh7m4pjkgt6n4kpt88hdeb8@4ax.com... > On Fri, 15 Mar 2002 12:55:19 GMT, "Pat Rogers" <progers@classwide.com> > wrote: > > >"John McCabe" <john.mccabe@emrad.ns.com> wrote in message > >news:3c91bfa3.1987537@news.demon.co.uk... > >> On Thu, 14 Mar 2002 15:12:21 -0500, "Marin David Condic" > >> <dont.bother.mcondic.auntie.spam@[acm.org> 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! > > > >Although there are several things I really like about C++, one of the things > >that I find shocking is that the programmer must remember to use a very slightly > >different syntax when calling delete on an allocated array, and that the other > >syntax will also compile and run -- and at the very least leak. (I understand > >the reason for this, don't bother to explain why; it still stinks!) That isn't > >the only such example, of course, but one that I find amazing. > > > >For example, the following is perfectly legal and wrong : > > > >char* p = new char[n]; > >delete p; > > > >I have to remember to say: > > > >delete[] p; > > No you don't... you just write it with Borland C++ Builder 5 or better > with CodeGuard turned on, and CodeGuard will complain about it all > over the place. But then why can't the compiler do that? ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-16 14:38 ` Pat Rogers @ 2002-03-16 14:56 ` DPH 2002-03-16 15:51 ` Preben Randhol 0 siblings, 1 reply; 79+ messages in thread From: DPH @ 2002-03-16 14:56 UTC (permalink / raw) On Sat, 16 Mar 2002 14:38:32 GMT, "Pat Rogers" <progers@classwide.com> wrote: >"DPH" <rally2xs@compuserve.com> wrote in message >news:s3369uo70srjh7m4pjkgt6n4kpt88hdeb8@4ax.com... >> On Fri, 15 Mar 2002 12:55:19 GMT, "Pat Rogers" <progers@classwide.com> >> wrote: >> >> >"John McCabe" <john.mccabe@emrad.ns.com> wrote in message >> >news:3c91bfa3.1987537@news.demon.co.uk... >> >> On Thu, 14 Mar 2002 15:12:21 -0500, "Marin David Condic" >> >> <dont.bother.mcondic.auntie.spam@[acm.org> 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! >> > >> >Although there are several things I really like about C++, one of the things >> >that I find shocking is that the programmer must remember to use a very >slightly >> >different syntax when calling delete on an allocated array, and that the >other >> >syntax will also compile and run -- and at the very least leak. (I >understand >> >the reason for this, don't bother to explain why; it still stinks!) That >isn't >> >the only such example, of course, but one that I find amazing. >> > >> >For example, the following is perfectly legal and wrong : >> > >> >char* p = new char[n]; >> >delete p; >> > >> >I have to remember to say: >> > >> >delete[] p; >> >> No you don't... you just write it with Borland C++ Builder 5 or better >> with CodeGuard turned on, and CodeGuard will complain about it all >> over the place. > >But then why can't the compiler do that? > Well, they _could_ build it in if they wanted to, and since its part of the IDE it might be said to be part of the compiler already, but this goes back to a post I made last month. I'm just wondering if Ada is all that much less error prone when you start comparing it with C++ development environments in the wildly popular platforms of Windows and Linux, but especially windows. There are just scads of tools to do about everything (except reliably find the memory leaks of C++, although there may be - and I just haven't run across it yet) and those tools are generally cheaper due to economy of scale. Don't get me wrong - I love Ada - but cheap and plentiful tools for other languages count for something, too. Couple that with being able to find 10 - 20 C++ programmers for every Ada programmer, and Ada loses a lot of business. Dave Head ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-16 14:56 ` DPH @ 2002-03-16 15:51 ` Preben Randhol 2002-03-16 16:39 ` DPH 0 siblings, 1 reply; 79+ messages in thread From: Preben Randhol @ 2002-03-16 15:51 UTC (permalink / raw) On Sat, 16 Mar 2002 09:56:41 -0500, DPH wrote: > > this goes back to a post I made last month. I'm just wondering if Ada > is all that much less error prone when you start comparing it with C++ > development environments in the wildly popular platforms of Windows > and Linux, but especially windows. There are just scads of tools to > do about everything (except reliably find the memory leaks of C++, > although there may be - and I just haven't run across it yet) and > those tools are generally cheaper due to economy of scale. Ask yourself: Why do so many tools exist for C++? -- Preben Randhol �For me, Ada95 puts back the joy in programming.� ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-16 15:51 ` Preben Randhol @ 2002-03-16 16:39 ` DPH 2002-03-16 19:51 ` Pat Rogers 2002-03-17 16:26 ` Steve Doiel 0 siblings, 2 replies; 79+ messages in thread From: DPH @ 2002-03-16 16:39 UTC (permalink / raw) On Sat, 16 Mar 2002 15:51:05 +0000 (UTC), Preben Randhol <randhol+abuse@pvv.org> wrote: >On Sat, 16 Mar 2002 09:56:41 -0500, DPH wrote: >> >> this goes back to a post I made last month. I'm just wondering if Ada >> is all that much less error prone when you start comparing it with C++ >> development environments in the wildly popular platforms of Windows >> and Linux, but especially windows. There are just scads of tools to >> do about everything (except reliably find the memory leaks of C++, >> although there may be - and I just haven't run across it yet) and >> those tools are generally cheaper due to economy of scale. > >Ask yourself: Why do so many tools exist for C++? 'Cuz tthey're necessary. 'Cuz there's such a huge user base that they could make money on them even if they weren't necessary - they would still be convenient and therefore saleable. The question is - do they compensate enough for C++'s inherent tendancy to fool programmers into doing something ugly, coupled with the hoarde of people that know the language, to make them viable competiton for Ada in some limited programming environments like Windows and Unix/Linux? Can you get an equally reliable program from an experienced C++ prgrammer with sophisticated tools that you get from an experienced Ada programmer for which the same tools don't exist? Dave Head ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-16 16:39 ` DPH @ 2002-03-16 19:51 ` Pat Rogers 2002-03-16 20:40 ` DPH 2002-03-17 19:31 ` Richard Riehle 2002-03-17 16:26 ` Steve Doiel 1 sibling, 2 replies; 79+ messages in thread From: Pat Rogers @ 2002-03-16 19:51 UTC (permalink / raw) "DPH" <rally2xs@compuserve.com> wrote in message news:00t69uso35hmunf5mpnfn37ggd9q59tctu@4ax.com... > On Sat, 16 Mar 2002 15:51:05 +0000 (UTC), Preben Randhol > <randhol+abuse@pvv.org> wrote: > > >On Sat, 16 Mar 2002 09:56:41 -0500, DPH wrote: > >> > >> this goes back to a post I made last month. I'm just wondering if Ada > >> is all that much less error prone when you start comparing it with C++ > >> development environments in the wildly popular platforms of Windows > >> and Linux, but especially windows. There are just scads of tools to > >> do about everything (except reliably find the memory leaks of C++, > >> although there may be - and I just haven't run across it yet) and > >> those tools are generally cheaper due to economy of scale. > > > >Ask yourself: Why do so many tools exist for C++? > > 'Cuz tthey're necessary. > > 'Cuz there's such a huge user base that they could make money on them > even if they weren't necessary - they would still be convenient and > therefore saleable. > > The question is - do they compensate enough for C++'s inherent > tendancy to fool programmers into doing something ugly, coupled with > the hoarde of people that know the language, to make them viable > competiton for Ada in some limited programming environments like > Windows and Unix/Linux? Can you get an equally reliable program from > an experienced C++ prgrammer with sophisticated tools that you get > from an experienced Ada programmer for which the same tools don't > exist? Not sure that works, though, for two reasons: 1) The tools are built into the language for the Ada side, so for the most part they do exist and are comparably priced nowadays, 2) The better question might be -- "At what price can these more or less equally reliable programs be created?" There is plenty of evidence that Ada is much more cost-effective than C for the application domain Ada was designed for. Unfortunately I don't know of much meaningful comparison data for Ada vs. C++. I know what my "gut" tells me, but that isn't so useful in this context. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-16 19:51 ` Pat Rogers @ 2002-03-16 20:40 ` DPH 2002-03-17 19:31 ` Richard Riehle 1 sibling, 0 replies; 79+ messages in thread From: DPH @ 2002-03-16 20:40 UTC (permalink / raw) On Sat, 16 Mar 2002 19:51:04 GMT, "Pat Rogers" <progers@classwide.com> wrote: >"DPH" <rally2xs@compuserve.com> wrote in message >news:00t69uso35hmunf5mpnfn37ggd9q59tctu@4ax.com... >> On Sat, 16 Mar 2002 15:51:05 +0000 (UTC), Preben Randhol >> <randhol+abuse@pvv.org> wrote: >> >> >On Sat, 16 Mar 2002 09:56:41 -0500, DPH wrote: >> >> >> >> this goes back to a post I made last month. I'm just wondering if Ada >> >> is all that much less error prone when you start comparing it with C++ >> >> development environments in the wildly popular platforms of Windows >> >> and Linux, but especially windows. There are just scads of tools to >> >> do about everything (except reliably find the memory leaks of C++, >> >> although there may be - and I just haven't run across it yet) and >> >> those tools are generally cheaper due to economy of scale. >> > >> >Ask yourself: Why do so many tools exist for C++? >> >> 'Cuz tthey're necessary. >> >> 'Cuz there's such a huge user base that they could make money on them >> even if they weren't necessary - they would still be convenient and >> therefore saleable. >> >> The question is - do they compensate enough for C++'s inherent >> tendancy to fool programmers into doing something ugly, coupled with >> the hoarde of people that know the language, to make them viable >> competiton for Ada in some limited programming environments like >> Windows and Unix/Linux? Can you get an equally reliable program from >> an experienced C++ prgrammer with sophisticated tools that you get >> from an experienced Ada programmer for which the same tools don't >> exist? > >Not sure that works, though, for two reasons: > > 1) The tools are built into the language for the Ada side, so for the >most part they do exist and are comparably priced nowadays, > > 2) The better question might be -- "At what price can these more or less >equally reliable programs be created?" > >There is plenty of evidence that Ada is much more cost-effective than C for the >application domain Ada was designed for. Unfortunately I don't know of much >meaningful comparison data for Ada vs. C++. I know what my "gut" tells me, >but that isn't so useful in this context. I suspect that Ada may still win in those environments too, but it might not be such a dramatic difference as in, say, Ada written to VxWorks. Dave Head ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-16 19:51 ` Pat Rogers 2002-03-16 20:40 ` DPH @ 2002-03-17 19:31 ` Richard Riehle 2002-03-17 21:49 ` Pat Rogers 2002-03-18 17:35 ` Marin David Condic 1 sibling, 2 replies; 79+ messages in thread From: Richard Riehle @ 2002-03-17 19:31 UTC (permalink / raw) Pat Rogers wrote: > There is plenty of evidence that Ada is much more cost-effective than C for the > application domain Ada was designed for. Unfortunately I don't know of much > meaningful comparison data for Ada vs. C++. I know what my "gut" tells me, > but that isn't so useful in this context. Pat, I have had some recent correspondence with Don Reifer regarding Ada's economic viability with respect to other languages. Don seems to feel that, while Ada may be a better language choice for weapon systems development, the economics are not currently in its favor. He has an article in the current issue of Crosstalk where he does some comparisons based on data he has been collecting over a long time. Don quite correctly challenges us to collect and develop the numbers to support our claims about Ada's productivity and its relevance in the current language environment. While some may be critical of Don for their own reasons, he is not an enemy of Ada. Rather, he has a consulting practice built on software metrics, and his credibility as a consultant demands he be honest with the data he develops. I raise this issue because you and others have asserted the "evidence" for the cost-effectiveness of Ada from time to time. If we do have such evidence, it is time to prepare a counter-argument to Reifer's Crosstalk article. He actually invites us to do so in that article. So, where are the metrics? Has anyone collected them in one place? Is anyone with a predilection for Statistics interested in taking on this kind of project? Oh, and I don't think a rant about Reifer is appropriate. He is an honest man trying to do his best with the tools and information he has. If we have other information, it is our responsibility to present it. Let's see if we can deal with this issue with other than an ad hominen attack. Richard Riehle ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-17 19:31 ` Richard Riehle @ 2002-03-17 21:49 ` Pat Rogers 2002-03-17 22:02 ` Pat Rogers 2002-03-18 7:22 ` Richard Riehle 2002-03-18 17:35 ` Marin David Condic 1 sibling, 2 replies; 79+ messages in thread From: Pat Rogers @ 2002-03-17 21:49 UTC (permalink / raw) "Richard Riehle" <richard@adaworks.com> wrote in message news:3C94EF0F.53049AA@adaworks.com... > Pat Rogers wrote: > > > There is plenty of evidence that Ada is much more cost-effective than C for the > > application domain Ada was designed for. Unfortunately I don't know of much > > meaningful comparison data for Ada vs. C++. I know what my "gut" tells me, > > but that isn't so useful in this context. > > Pat, > > I have had some recent correspondence with Don Reifer regarding Ada's > economic viability with respect to other languages. Don seems to feel > that, while Ada may be a better language choice for weapon systems > development, the economics are not currently in its favor. He has an > article in the current issue of Crosstalk where he does some comparisons > based on data he has been collecting over a long time. > > Don quite correctly challenges us to collect and develop the numbers > to support our claims about Ada's productivity and its relevance in > the current language environment. While some may be critical of > Don for their own reasons, he is not an enemy of Ada. Rather, he > has a consulting practice built on software metrics, and his credibility > as a consultant demands he be honest with the data he develops. > > I raise this issue because you and others have asserted the "evidence" > for the cost-effectiveness of Ada from time to time. If we do have > such evidence, it is time to prepare a counter-argument to Reifer's > Crosstalk article. He actually invites us to do so in that article. > > So, where are the metrics? The "Programming Languages and Lifecycle Cost" study shows metric data strongly in favor of Ada over C, and of course the "Zeigler Paper" does as well. The same issue of Crosstalk has an article by Peter Amey entitled "Correctness by Construction: Better Can Also Be Cheaper". On page 25 in that article, he quotes a study in which Ada only had 10 percent the residual errors on code written in C. Besides showing that in practice it does indeed matter what language one uses, it also shows the cost advantage of Ada over C for that domain. > Has anyone collected them in one place? I wonder about the ARA site... > Is anyone with a predilection for Statistics interested in taking on > this kind of project? That would not be me -- I'm just a poor developer. > Oh, and I don't think a rant about Reifer is appropriate. He is an > honest man trying to do his best with the tools and information he > has. If we have other information, it is our responsibility to present > it. Let's see if we can deal with this issue with other than an ad > hominen attack. Although I am in Mark Twain's camp when it comes to statistics ("Lies, damn lies, and statistics!"), I'm a bit confused by this last paragraph. I've known Don since long before he was at AJPO; I don't recall ever attacking him! --- Patrick Rogers Consulting and Training in: http://www.classwide.com Real-Time/OO Languages progers@classwide.com Hard Deadline Schedulability Analysis (281)648-3165 Software Fault Tolerance ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-17 21:49 ` Pat Rogers @ 2002-03-17 22:02 ` Pat Rogers 2002-03-18 22:32 ` Randy Brukardt 2002-03-18 7:22 ` Richard Riehle 1 sibling, 1 reply; 79+ messages in thread From: Pat Rogers @ 2002-03-17 22:02 UTC (permalink / raw) Sorry to follow up to my own post... > > So, where are the metrics? > > The "Programming Languages and Lifecycle Cost" study shows metric data strongly > in favor of Ada over C, and of course the "Zeigler Paper" does as well. > > The same issue of Crosstalk has an article by Peter Amey entitled "Correctness > by Construction: Better Can Also Be Cheaper". On page 25 in that article, he > quotes a study in which Ada only had 10 percent the residual errors on code > written in C. Besides showing that in practice it does indeed matter what > language one uses, it also shows the cost advantage of Ada over C for that > domain. An October 1998 letter to the editor of Crosstalk from Capers Jones is also intersting in the context of Don's article: "Software Metrics Hazards Elizabeth Starrett's article, "Measurement 101," Crosstalk, August 1998, was interesting and well written, but it left out a critical point. Metrics based on "source lines of code" move backward when comparing software applications written in different programming languages. The version in the low-level language will look better than the version in the high-level language. In an article aimed at metrics novices, it is very important to point out some of the known hazards of software metrics. The fact that lines of code can't be used to measure economic productivity is definitely a known hazard that should be stressed. In a comparative study of 10 versions of the same period using 10 different programming languages (Ada 83, Ada95, C, C++, Objective C, PL/I, Assembler, CHILL, Pascal, and Smalltalk), the lines of code metric failed to show either the highest productivity or best quality. Overall, the lowest cost and fewest defects were found in Smalltalk and Ada95, but the lines of code metric favored assembler. Function points correctly identified Smalltalk and Ada95 as being superior, but lines of code failed to do this. Capers Jones Software Productivity Research " > > Has anyone collected them in one place? > > I wonder about the ARA site... Definitely has some material: http://www.adaic.org/whyada/index.html could use more. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-17 22:02 ` Pat Rogers @ 2002-03-18 22:32 ` Randy Brukardt 2002-03-18 22:47 ` Pat Rogers 0 siblings, 1 reply; 79+ messages in thread From: Randy Brukardt @ 2002-03-18 22:32 UTC (permalink / raw) Pat Rogers wrote in message ... >> I wonder about the ARA site... > >Definitely has some material: > >http://www.adaic.org/whyada/index.html > >could use more. I agree. If anyone has relatively recent material that they think ought to be added to the site, send it along to us. Our problem has been we just don't have all of the content to post that we'd like. I expect that a lot of it exists, but we have to know about it... Randy Brukardt Technical Webmaster, adaic.org ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-18 22:32 ` Randy Brukardt @ 2002-03-18 22:47 ` Pat Rogers 0 siblings, 0 replies; 79+ messages in thread From: Pat Rogers @ 2002-03-18 22:47 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:u9cr933d0a62d9@corp.supernews.com... > Pat Rogers wrote in message ... > >> I wonder about the ARA site... > > > >Definitely has some material: > > > >http://www.adaic.org/whyada/index.html > > > >could use more. > > > I agree. > > If anyone has relatively recent material that they think ought to be > added to the site, send it along to us. Our problem has been we just > don't have all of the content to post that we'd like. I expect that a > lot of it exists, but we have to know about it... Can it have a link to the Capers Jones letter to the editor of Crosstalk? http://www.stsc.hill.af.mil/crosstalk/1998/oct/letters.asp It is particularly relevant because it argues that SLOC is not the right unit of measurement for productivity, and, in that light, Ada95 and Smalltalk are the most productive. The problem with a link, I suppose, is that we have no control over how long the referenced page exists. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-17 21:49 ` Pat Rogers 2002-03-17 22:02 ` Pat Rogers @ 2002-03-18 7:22 ` Richard Riehle 1 sibling, 0 replies; 79+ messages in thread From: Richard Riehle @ 2002-03-18 7:22 UTC (permalink / raw) Pat Rogers wrote: > Although I am in Mark Twain's camp when it comes to statistics ("Lies, damn > lies, and statistics!"), I'm a bit confused by this last paragraph. I've known > Don since long before he was at AJPO; I don't recall ever attacking him! Sorry, Pat. I did not mean that last part for you. In fact, I have not known you to be someone who does attack anyone. What I meant was that some people do have feelings about Don that have nothing to do with his contribution, and I was simply indicating that I did not want those people to throw a lot of irrelevant personal feelings into this discussion. Richard Riehle ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-17 19:31 ` Richard Riehle 2002-03-17 21:49 ` Pat Rogers @ 2002-03-18 17:35 ` Marin David Condic 1 sibling, 0 replies; 79+ messages in thread From: Marin David Condic @ 2002-03-18 17:35 UTC (permalink / raw) At least part of the problem is that there may be companies who have collected internal metrics on projects that demonstrate superior performance for Ada projects, but they may be reluctant to share that data with the world for a variety of reasons. It perhaps requires that some university decide to do some studies whereby the companies may get some asurances of protection of their data from competitors, exposure of processes from competitors, etc. I agree that it would be good to have studies that demonstrate better Ada performance - its just a problem of who is going to pay for it? MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Richard Riehle" <richard@adaworks.com> wrote in message news:3C94EF0F.53049AA@adaworks.com... > > I have had some recent correspondence with Don Reifer regarding Ada's > economic viability with respect to other languages. Don seems to feel > that, while Ada may be a better language choice for weapon systems > development, the economics are not currently in its favor. He has an > article in the current issue of Crosstalk where he does some comparisons > based on data he has been collecting over a long time. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-16 16:39 ` DPH 2002-03-16 19:51 ` Pat Rogers @ 2002-03-17 16:26 ` Steve Doiel 1 sibling, 0 replies; 79+ messages in thread From: Steve Doiel @ 2002-03-17 16:26 UTC (permalink / raw) "DPH" <rally2xs@compuserve.com> wrote in message news:00t69uso35hmunf5mpnfn37ggd9q59tctu@4ax.com... [snip] > Windows and Unix/Linux? Can you get an equally reliable program from > an experienced C++ prgrammer with sophisticated tools that you get > from an experienced Ada programmer for which the same tools don't > exist? A couple of questions I find more more interesting are: Can you get an equally reliable program from a inexperienced C++ programmer with sophisticated tools than you get from a inexperienced Ada programmer for which the same tools don't exist? And: Can you get an equally reliable program from a experienced C++ programmer with sophisticated tools than you get from a inexperienced Ada programmer for which the same tools don't exist? Although I don't know what this has to do with memory leaks in Ada. SteveD > Dave Head > ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-16 9:13 ` DPH 2002-03-16 14:38 ` Pat Rogers @ 2002-03-16 20:18 ` Robert A Duff 2002-03-16 20:36 ` DPH 1 sibling, 1 reply; 79+ messages in thread From: Robert A Duff @ 2002-03-16 20:18 UTC (permalink / raw) DPH <rally2xs@compuserve.com> writes: > >I have to remember to say: > > > >delete[] p; > > No you don't... you just write it with Borland C++ Builder 5 or better > with CodeGuard turned on, and CodeGuard will complain about it all > over the place. I've never used Borland C++ Builder 5, but I don't believe it can complain about this sort of thing at compile time in the general case, because it is impossible to distinguish a pointer-to-thing from a pointer-to-array-of-things. - Bob ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-16 20:18 ` Robert A Duff @ 2002-03-16 20:36 ` DPH 0 siblings, 0 replies; 79+ messages in thread From: DPH @ 2002-03-16 20:36 UTC (permalink / raw) On Sat, 16 Mar 2002 20:18:31 GMT, Robert A Duff <bobduff@shell01.TheWorld.com> wrote: >DPH <rally2xs@compuserve.com> writes: > >> >I have to remember to say: >> > >> >delete[] p; >> >> No you don't... you just write it with Borland C++ Builder 5 or better >> with CodeGuard turned on, and CodeGuard will complain about it all >> over the place. > >I've never used Borland C++ Builder 5, but I don't believe it can >complain about this sort of thing at compile time in the general case, >because it is impossible to distinguish a pointer-to-thing from a >pointer-to-array-of-things. > >- Bob CodeGuard's pretty smart. It knows, even if the language doesn't. When I turned it onto the code someone else built without CodeGuard, it gave me a whole pile of error messages with those double bracket required to delete array errors. It was called out in the error window like any other error, and I clicked on it and it took me right to the particular line. I just stuck those brackets on the delete and the problem was solved. Dave Head ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 9:37 ` John McCabe 2002-03-15 12:55 ` Pat Rogers @ 2002-03-15 14:20 ` Marin David Condic 2002-03-18 17:54 ` Warren W. Gay VE3WWG 2002-03-15 16:00 ` Hyman Rosen 2 siblings, 1 reply; 79+ messages in thread From: Marin David Condic @ 2002-03-15 14:20 UTC (permalink / raw) Clearly, there will be stylistic differences depending on the methodology employed in designing the program. Object Oriented stuff tends to deal with things easier if you have pointers to things. Hence OOP stuff in Ada would have more dynamic allocation than a functional approach or some other strategy. I'll concede that point. But being an active C programmer at the moment (and sadly shaking my head and telling my associates "It doesn't have to be this way..." as we spend months debugging and chasing among other typical C problems - memory leaks) I find myself having to deal with dynamically allocated data in the most mundane of circumstances - often because that's just what many of the library calls return to you. (The libraries we are using - not necessarily the standard C libraries.) You just find yourself doing mallocs (Bumper sticker: "Free The Mallocs!") all over the place and referencing things with pointers all the time just because that's the way C wants you to do it. Ada doesn't make it necessary to use dynamic allocation or pointers to do mundane tasks. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "John McCabe" <john.mccabe@emrad.ns.com> wrote in message news:3c91bfa3.1987537@news.demon.co.uk... > > 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... ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 14:20 ` Marin David Condic @ 2002-03-18 17:54 ` Warren W. Gay VE3WWG 2002-03-18 19:54 ` Hyman Rosen ` (3 more replies) 0 siblings, 4 replies; 79+ messages in thread From: Warren W. Gay VE3WWG @ 2002-03-18 17:54 UTC (permalink / raw) Marin David Condic wrote: ... > But being an active C programmer at the moment (and sadly shaking my head > and telling my associates "It doesn't have to be this way..." as we spend > months debugging and chasing among other typical C problems - memory leaks) > I find myself having to deal with dynamically allocated data in the most > mundane of circumstances - often because that's just what many of the > library calls return to you. (The libraries we are using - not necessarily > the standard C libraries.) You just find yourself doing mallocs (Bumper > sticker: "Free The Mallocs!") all over the place and referencing things with > pointers all the time just because that's the way C wants you to do it. Ada > doesn't make it necessary to use dynamic allocation or pointers to do > mundane tasks. > > MDC This was actually one of my first observations when I started learning Ada95. A C function does not have a simple way to return a string (a few basic choices exist, though one can vary the theme somewhat). C++ gets around this with objects, but they end up resorting to malloc() inside of the object to carry this off. (excuse the lack of const keywords in these C examples) : /* The malloc approach */ char *uppercase(char *s) { char *buf = strdup(s); /* Clone the string for modification */ ...do uppercasing on buf... return buf; } The caller gets a dynamically allocated string back, and must free it when he is finished with it. Ug. /* The dirty old static buffer approach */ char *uppercase(char *s) { static char my_big_buf[4096]; strcpy(my_big_buf,s); ...do uppercasing on my_big_buf... return my_big_buf; } This is very bad, because it won't work for all sized strings. It is also very unsafe in threaded programs. Ug! /* The user supplied buffer approach */ char *uppercase(char *s, char *user_buf) { strcpy(user_buf,s); ...do uppercasing in user_buf... return user_buf; } This is ugly because the user must supply a receiving buffer. However, this is also the safest and thread safe way to do it, provided the caller has not made a size error on the supplied buffer. Another variation is to supply a buffer size, and then somehow decide how to deal with strings that are too long (truncate, abort, or whatever). In Ada95, this mundane issue is mundane and easy : function Uppercase(S : String) return String is UC : String(1..S'Length) := S; begin ...uppercase UC... return UC; end Uppercase; The caller has equal convenience : declare UC : String := Uppercase("Take that!"); begin ... This is so much easier, and most important *reliable*. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-18 17:54 ` Warren W. Gay VE3WWG @ 2002-03-18 19:54 ` Hyman Rosen 2002-03-18 20:34 ` Larry Kilgallen 2002-03-18 22:18 ` Marin David Condic ` (2 subsequent siblings) 3 siblings, 1 reply; 79+ messages in thread From: Hyman Rosen @ 2002-03-18 19:54 UTC (permalink / raw) Warren W. Gay VE3WWG wrote: > In Ada95, this mundane issue is mundane and easy : > function Uppercase(S : String) return String is > UC : String(1..S'Length) := S; > begin > ...uppercase UC... > return UC; > end Uppercase; > > The caller has equal convenience : > declare > UC : String := Uppercase("Take that!"); > begin > ... > This is so much easier, and most important *reliable*. There are still trade-offs to this approach. It's inapplicable when you need to generate more than a single result, since the technique can't be applied to out parameters or to record members. And it will most likely require an extra copy of the return value, since it's difficult to construct a variable-size array in the callers's frame. But it is very nice. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-18 19:54 ` Hyman Rosen @ 2002-03-18 20:34 ` Larry Kilgallen 2002-03-18 21:18 ` Hyman Rosen 0 siblings, 1 reply; 79+ messages in thread From: Larry Kilgallen @ 2002-03-18 20:34 UTC (permalink / raw) In article <3C9645DD.4020006@mail.com>, Hyman Rosen <hyrosen@mail.com> writes: > Warren W. Gay VE3WWG wrote: >> The caller has equal convenience : >> declare >> UC : String := Uppercase("Take that!"); >> begin >> ... > to out parameters or to record members. And it will most > likely require an extra copy of the return value, since > it's difficult to construct a variable-size array in the > callers's frame. Construction of the variable-size array in the frame of the caller is what is done by the portion of Warren's post shown above. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-18 20:34 ` Larry Kilgallen @ 2002-03-18 21:18 ` Hyman Rosen 2002-03-18 21:45 ` Larry Kilgallen 2002-03-22 0:25 ` Matthew Woodcraft 0 siblings, 2 replies; 79+ messages in thread From: Hyman Rosen @ 2002-03-18 21:18 UTC (permalink / raw) Larry Kilgallen wrote: >>>declare >>> UC : String := Uppercase("Take that!"); > > Construction of the variable-size array in the frame of the > caller is what is done by the portion of Warren's post shown > above. Sure, but I have to assume that the value constructed in the called routine then needs to be copied to the callers frame instead of being constructed in place. I don't see how this can be otherwise using a conventional stack, unless you don't pop the stack after a call, which would blow the stack away if you had the call in a loop. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-18 21:18 ` Hyman Rosen @ 2002-03-18 21:45 ` Larry Kilgallen 2002-03-20 1:19 ` Hyman Rosen 2002-03-22 0:25 ` Matthew Woodcraft 1 sibling, 1 reply; 79+ messages in thread From: Larry Kilgallen @ 2002-03-18 21:45 UTC (permalink / raw) In article <3C9659B6.6030204@mail.com>, Hyman Rosen <hyrosen@mail.com> writes: > Larry Kilgallen wrote: >>>>declare >>>> UC : String := Uppercase("Take that!"); > > >> Construction of the variable-size array in the frame of the >> caller is what is done by the portion of Warren's post shown >> above. > > Sure, but I have to assume that the value constructed in the > called routine then needs to be copied to the callers frame > instead of being constructed in place. I don't see how this > can be otherwise using a conventional stack, unless you don't > pop the stack after a call, which would blow the stack away > if you had the call in a loop. That code snippet _is_ in the caller's frame. Uppercase is the function being called. The bytes do get copied (obviously) to the caller's frame, but what you see above is the entire syntax for doing that. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-18 21:45 ` Larry Kilgallen @ 2002-03-20 1:19 ` Hyman Rosen 2002-03-20 17:06 ` Warren W. Gay VE3WWG 2002-03-20 17:48 ` Marin David Condic 0 siblings, 2 replies; 79+ messages in thread From: Hyman Rosen @ 2002-03-20 1:19 UTC (permalink / raw) Larry Kilgallen wrote: > That code snippet _is_ in the caller's frame. Uppercase is the > function being called. The bytes do get copied (obviously) to > the caller's frame, but what you see above is the entire syntax > for doing that. Yes, that's exactly what I was trying to say! My point was that in the various C techniques, the bytes of the result get constructed once, and then don't have to be copied as part of the function return, whereas returning a String in Ada will involve copying the bytes. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-20 1:19 ` Hyman Rosen @ 2002-03-20 17:06 ` Warren W. Gay VE3WWG 2002-03-20 17:56 ` Larry Kilgallen 2002-03-20 17:48 ` Marin David Condic 1 sibling, 1 reply; 79+ messages in thread From: Warren W. Gay VE3WWG @ 2002-03-20 17:06 UTC (permalink / raw) Hyman Rosen wrote: > Larry Kilgallen wrote: > >> That code snippet _is_ in the caller's frame. Uppercase is the >> function being called. The bytes do get copied (obviously) to >> the caller's frame, but what you see above is the entire syntax >> for doing that. > > Yes, that's exactly what I was trying to say! > My point was that in the various C techniques, > the bytes of the result get constructed once, > and then don't have to be copied as part of > the function return, whereas returning a String > in Ada will involve copying the bytes. This can be a performance issue if the string is huge. But for mundane strings, the cost of copying it is much cheaper than the malloc/free cost, for example. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-20 17:06 ` Warren W. Gay VE3WWG @ 2002-03-20 17:56 ` Larry Kilgallen 0 siblings, 0 replies; 79+ messages in thread From: Larry Kilgallen @ 2002-03-20 17:56 UTC (permalink / raw) In article <3C98C195.2030705@home.com>, "Warren W. Gay VE3WWG" <ve3wwg@home.com> writes: > Hyman Rosen wrote: > >> Larry Kilgallen wrote: >> >>> That code snippet _is_ in the caller's frame. Uppercase is the >>> function being called. The bytes do get copied (obviously) to >>> the caller's frame, but what you see above is the entire syntax >>> for doing that. >> >> Yes, that's exactly what I was trying to say! >> My point was that in the various C techniques, >> the bytes of the result get constructed once, >> and then don't have to be copied as part of >> the function return, whereas returning a String >> in Ada will involve copying the bytes. > > This can be a performance issue if the string is huge. But for > mundane strings, the cost of copying it is much cheaper than the > malloc/free cost, for example. Certainly for huge strings, more attention to performance is required. In programs with which I deal, however, huge data structures are quite outnumbered by tiny data structures. Ignoring performance on the tiny ones leaves more time to worry about performance on the hugh ones. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-20 1:19 ` Hyman Rosen 2002-03-20 17:06 ` Warren W. Gay VE3WWG @ 2002-03-20 17:48 ` Marin David Condic 1 sibling, 0 replies; 79+ messages in thread From: Marin David Condic @ 2002-03-20 17:48 UTC (permalink / raw) Well, yeah, that's true. A function returning a String would need to construct the string then copy it to the caller's space. C's allocation and return of a pointer doesn't require that. Note that you *can* do the same in Ada - you just aren't *forced* to do that. Hence, if your application isn't time-critical or memory-critical, you don't have to take the risk of memory leaks by doing so. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Hyman Rosen" <hyrosen@mail.com> wrote in message news:3C97E496.20404@mail.com... > > Yes, that's exactly what I was trying to say! > My point was that in the various C techniques, > the bytes of the result get constructed once, > and then don't have to be copied as part of > the function return, whereas returning a String > in Ada will involve copying the bytes. > ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-18 21:18 ` Hyman Rosen 2002-03-18 21:45 ` Larry Kilgallen @ 2002-03-22 0:25 ` Matthew Woodcraft 2002-03-22 5:10 ` Hyman Rosen 1 sibling, 1 reply; 79+ messages in thread From: Matthew Woodcraft @ 2002-03-22 0:25 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> writes: > Sure, but I have to assume that the value constructed in the > called routine then needs to be copied to the callers frame > instead of being constructed in place. I don't see how this > can be otherwise using a conventional stack, unless you don't > pop the stack after a call, which would blow the stack away > if you had the call in a loop. Well, if you want to know how it can be done, you could try starting at <http://savannah.gnu.org/cgi-bin/viewcvs/gcc/gcc/gcc/function.c?rev=HEAD&content-type=text/vnd.viewcvs-markup>. See the keep_stack_depressed() function. -M- ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-22 0:25 ` Matthew Woodcraft @ 2002-03-22 5:10 ` Hyman Rosen 0 siblings, 0 replies; 79+ messages in thread From: Hyman Rosen @ 2002-03-22 5:10 UTC (permalink / raw) Matthew Woodcraft wrote: > See the keep_stack_depressed() function. I see. Turns any function into an alloca() variant. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-18 17:54 ` Warren W. Gay VE3WWG 2002-03-18 19:54 ` Hyman Rosen @ 2002-03-18 22:18 ` Marin David Condic 2002-03-20 20:49 ` Bertrand Augereau 2002-03-21 4:31 ` Will 3 siblings, 0 replies; 79+ messages in thread From: Marin David Condic @ 2002-03-18 22:18 UTC (permalink / raw) Excellent examples. That's the kind of thing I had in mind. I don't object to relying on dynamic allocation for the more sophisticated things like building data structures, but I'd prefer not to do it for the routine stuff that has to happen all over the code. This is why I suggest that C tempts fate with respect to memory leaks because stylistically, you just have to do more memory management in so many more cases. You *can* do similar things in Ada if so inclined. Nothing stops you from doing some version of "new String..." and keeping pointers to everything & using them for all your referencing of data. Its just that most of the time you don't have to and that leads to fewer stupid programming errors. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message news:3C9629E3.8030109@home.com... > > This was actually one of my first observations when I started learning Ada95. > A C function does not have a simple way to return a string (a few basic ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-18 17:54 ` Warren W. Gay VE3WWG 2002-03-18 19:54 ` Hyman Rosen 2002-03-18 22:18 ` Marin David Condic @ 2002-03-20 20:49 ` Bertrand Augereau 2002-03-21 4:31 ` Will 3 siblings, 0 replies; 79+ messages in thread From: Bertrand Augereau @ 2002-03-20 20:49 UTC (permalink / raw) > This was actually one of my first observations when I started learning Ada95. > A C function does not have a simple way to return a string (a few basic > choices exist, though one can vary the theme somewhat). C++ gets around this > with objects, but they end up resorting to malloc() inside of the object to > carry this off. (excuse the lack of const keywords in these C examples) : There's no "getting around" in C++, you have std::string which is a standard object. And you don't use "malloc", but "new" in C++. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-18 17:54 ` Warren W. Gay VE3WWG ` (2 preceding siblings ...) 2002-03-20 20:49 ` Bertrand Augereau @ 2002-03-21 4:31 ` Will 3 siblings, 0 replies; 79+ messages in thread From: Will @ 2002-03-21 4:31 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message news:<3C9629E3.8030109@home.com>... > > This was actually one of my first observations when I started learning Ada95. > A C function does not have a simple way to return a string (a few basic > choices exist, though one can vary the theme somewhat). C++ gets around this > with objects, but they end up resorting to malloc() inside of the object to > carry this off. (excuse the lack of const keywords in these C examples) : > > /* The malloc approach */ > char *uppercase(char *s) { > char *buf = strdup(s); /* Clone the string for modification */ > > ...do uppercasing on buf... > return buf; > } > > The caller gets a dynamically allocated string back, and must free it when > he is finished with it. Ug. > > /* The dirty old static buffer approach */ > char *uppercase(char *s) { > static char my_big_buf[4096]; > > strcpy(my_big_buf,s); > ...do uppercasing on my_big_buf... > return my_big_buf; > } > > This is very bad, because it won't work for all sized strings. It is also > very unsafe in threaded programs. Ug! > > /* The user supplied buffer approach */ > char *uppercase(char *s, char *user_buf) { > strcpy(user_buf,s); > ...do uppercasing in user_buf... > return user_buf; > } The horrible thing about these examples is the absence of bounds checkings. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 9:37 ` John McCabe 2002-03-15 12:55 ` Pat Rogers 2002-03-15 14:20 ` Marin David Condic @ 2002-03-15 16:00 ` Hyman Rosen 2002-03-15 21:59 ` Chad R. Meiners 2 siblings, 1 reply; 79+ messages in thread From: Hyman Rosen @ 2002-03-15 16:00 UTC (permalink / raw) John McCabe wrote: > 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! If I'm not mistaken (not really knowing Ada), Ada.UncheckedDeallocation is a generic procedure which must be instantiated for each access type you are interested in freeing. So if you want that behavior in C++, you should have no qualms about adding your own procedure in the same way. template<typename T> void unchecked_deallocation(T *&p) { delete p; p = 0; } The counter argument is that dangling pointers are a problem where they have been copied into other data structures, so nulling one particular variable which is holding the pointer isn't all that useful. Also, freeing memory tends to happen as part of the process of cleaning up a data structure which is itself about to disappear, so again nulling the pointer isn't going to accomplish much. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 16:00 ` Hyman Rosen @ 2002-03-15 21:59 ` Chad R. Meiners 2002-03-17 5:43 ` Kevin Cline 0 siblings, 1 reply; 79+ messages in thread From: Chad R. Meiners @ 2002-03-15 21:59 UTC (permalink / raw) "Hyman Rosen" <hyrosen@mail.com> wrote in message news:3C921A81.9060708@mail.com... > The counter argument is that dangling pointers are a problem where they > have been copied into other data structures, so nulling one particular > variable which is holding the pointer isn't all that useful. Also, > freeing memory tends to happen as part of the process of cleaning up a > data structure which is itself about to disappear, so again nulling the > pointer isn't going to accomplish much. > This counter argument is weak at best since it is very poor design to allow more than one pointer to a block of allocated memory without having the ablility to invalidate them all when you deallocate that block. Therefore, since proper program design avoids the dangling pointer problem, nulling the pointer provides a useful safeguard against accessing deallocated memory. -CRM ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 21:59 ` Chad R. Meiners @ 2002-03-17 5:43 ` Kevin Cline 2002-03-17 7:22 ` Chad R. Meiners 2002-03-17 7:27 ` Hyman Rosen 0 siblings, 2 replies; 79+ messages in thread From: Kevin Cline @ 2002-03-17 5:43 UTC (permalink / raw) "Chad R. Meiners" <crmeiners@hotmail.com> wrote in message news:<a6tq2m$rnb$1@msunews.cl.msu.edu>... > "Hyman Rosen" <hyrosen@mail.com> wrote in message > news:3C921A81.9060708@mail.com... > > The counter argument is that dangling pointers are a problem where they > > have been copied into other data structures, so nulling one particular > > variable which is holding the pointer isn't all that useful. Also, > > freeing memory tends to happen as part of the process of cleaning up a > > data structure which is itself about to disappear, so again nulling the > > pointer isn't going to accomplish much. > > > > This counter argument is weak at best since it is very poor design to allow > more than one pointer to a block of allocated memory without having the > ablility to invalidate them all when you deallocate that block. Therefore, > since proper program design avoids the dangling pointer problem, nulling the > pointer provides a useful safeguard against accessing deallocated memory. Dereferencing nil is just as fatal to program execution. The only advantage is that it is more easily debugged because the crash is immediate. Any code that keeps invalid pointers around, whether null or not, is poorly crafted. Good programmers don't much care about the state of a pointer variable after delallocation because the variable is either going to be reassigned immediately or is going out of scope. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-17 5:43 ` Kevin Cline @ 2002-03-17 7:22 ` Chad R. Meiners 2002-03-18 4:09 ` Kevin Cline 2002-03-18 17:38 ` Warren W. Gay VE3WWG 2002-03-17 7:27 ` Hyman Rosen 1 sibling, 2 replies; 79+ messages in thread From: Chad R. Meiners @ 2002-03-17 7:22 UTC (permalink / raw) "Kevin Cline" <kcline@optelnow.net> wrote in message > Dereferencing nil is just as fatal to program execution. The only advantage > is that it is more easily debugged because the crash is immediate. > Any code that keeps invalid pointers around, whether null or not, is > poorly crafted. Good programmers don't much care about the state > of a pointer variable after delallocation because the variable > is either going to be reassigned immediately or is going out of scope. While it is true that dereferencing a null pointer will raise a constraint_error exception, exceptions can be handled gracefully and null pointers can be guarded against. Pointers off to nowhere are very difficult to detect in a general manner. Your assertion about good programmers not caring about the state of a pointer, however, is false. For example, let's say we want to build a hash table of complex objects. This can be accomplished via an array of pointers to the given object type. Here is a case where we will want to reuse the pointers (although not necessarily immediately) since we might delete and add a bunch of objects throughout the program's lifetime. Here we can clearly use the state of the pointers to hold valuable information about the table. Is this use improper? No, this is actually a case where using pointers is the right way to go about solving the problem. Other examples of null pointers being useful are linked lists and tree data structures. This is one of the many reasons why I like Ada. The designers did a very good job with access types. I have never encountered a situation where I felt I was being forced by the language to use a pointer improperly in the six years I have been programming with it. I have found that Ada's design is embedded with much wisdom; if you ask, "Why does Ada do/have this?", the answer often makes you a better programmer. -CRM ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-17 7:22 ` Chad R. Meiners @ 2002-03-18 4:09 ` Kevin Cline 2002-03-18 16:54 ` Chad R. Meiners 2002-03-18 17:38 ` Warren W. Gay VE3WWG 1 sibling, 1 reply; 79+ messages in thread From: Kevin Cline @ 2002-03-18 4:09 UTC (permalink / raw) "Chad R. Meiners" <crmeiners@hotmail.com> wrote in message news:<a71ffd$5c9$1@msunews.cl.msu.edu>... > "Kevin Cline" <kcline@optelnow.net> wrote in message > > Dereferencing nil is just as fatal to program execution. The only > advantage > > is that it is more easily debugged because the crash is immediate. > > Any code that keeps invalid pointers around, whether null or not, is > > poorly crafted. Good programmers don't much care about the state > > of a pointer variable after delallocation because the variable > > is either going to be reassigned immediately or is going out of scope. > > While it is true that dereferencing a null pointer will raise a > constraint_error exception, exceptions can be handled gracefully and null > pointers can be guarded against. Pointers off to nowhere are very difficult > to detect in a general manner. > > Your assertion about good programmers not caring about the state of a > pointer, however, is false. For example, let's say we want to build a hash > table of complex objects. Why wouldn't I use one of the many fine generic implementations already available? > This can be accomplished via an array of pointers > to the given object type. Here is a case where we will want to reuse the > pointers (although not necessarily immediately) since we might delete and > add a bunch of objects throughout the program's lifetime. Here we can > clearly use the state of the pointers to hold valuable information about the > table. Is this use improper? No, this is actually a case where using > pointers is the right way to go about solving the problem. Other examples > of null pointers being useful are linked lists and tree data structures. Certainly it is, but in my experience the implementation of such fundamental data structures is a small part of application code, and not often the source of memory leaks since it's clear which code is responsible for deallocation. > > This is one of the many reasons why I like Ada. The designers did a very > good job with access types. I have never encountered a situation where I > felt I was being forced by the language to use a pointer improperly in the > six years I have been programming with it. I don't think there any languages that force one to use a pointer improperly. There are some languages where a pointer can be used improperly with less typing that is necessary in Ada. Ada makes the undesirable inconvenient. It forces the inexpert to ask questions of their betters, because without guidance they won't be able to appease the compiler. This can be a good thing. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-18 4:09 ` Kevin Cline @ 2002-03-18 16:54 ` Chad R. Meiners 0 siblings, 0 replies; 79+ messages in thread From: Chad R. Meiners @ 2002-03-18 16:54 UTC (permalink / raw) "Kevin Cline" <kcline@optelnow.net> wrote in message news:dcfe911f.0203172009.76c72def@posting.google.com... > > Why wouldn't I use one of the many fine generic implementations > already available? I hope this is a gentle reponse ;-) You made an absolute statement about good programmers. Absolute statements which are not true are easy to disprove since all you need is one case where the absolute does not hold. I was trying to get to you to stop making absolute statements without first going through some amount of reasoning about whether or not they hold. I did this by kindly pointing out flaws in your argument. Instead of accepting that your absolute assertion does not hold you ask why would anyone care about this case (one obvious reason is that it disproves your assertion ;-). This simply is not an acceptable method of arguing. -CRM ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-17 7:22 ` Chad R. Meiners 2002-03-18 4:09 ` Kevin Cline @ 2002-03-18 17:38 ` Warren W. Gay VE3WWG 2002-03-19 9:21 ` John McCabe 1 sibling, 1 reply; 79+ messages in thread From: Warren W. Gay VE3WWG @ 2002-03-18 17:38 UTC (permalink / raw) Chad R. Meiners wrote: > "Kevin Cline" <kcline@optelnow.net> wrote in message > >>Dereferencing nil is just as fatal to program execution. The only >> > advantage > >>is that it is more easily debugged because the crash is immediate. >>Any code that keeps invalid pointers around, whether null or not, is >>poorly crafted. Good programmers don't much care about the state >>of a pointer variable after delallocation because the variable >>is either going to be reassigned immediately or is going out of scope. >> > > While it is true that dereferencing a null pointer will raise a > constraint_error exception, exceptions can be handled gracefully and null > pointers can be guarded against. Pointers off to nowhere are very difficult > to detect in a general manner. My own personal observation is that C/C++ programmers will err on the side of efficiency, rather than safety. After a free()/delete, they'll usually not set the pointer to null. It also comes up in functions a lot, like this: void myfun() { char *cp; /* work pointer */ Rather than code : void myfun() { char *cp = NULL; /* work pointer */ The former is very often chosen instead to avoid the overhead of setting the value to null (or to avoid having to type the initial assignment, by lazy programmers). The consequence very often is that later on, in larger functions, someone will add some functionality or correct it, and get stung by a bad pointer with garbage in it. If you're lucky, it will be such that a fault occurs. Otherwise, memory corruption galore sets in (if used for storing values or for copying strings) that will create all kinds of fun. I have seen this sort of thing create "side effects" on rare occasions in production C code for years, until it was finally tracked down. The intermittant problem is the worst kind to debug. I like the Ada safety factor with their access types, and the way Unchecked_Deallocation sets the pointer back to null. With the speed of processors today, it is a small price to pay for software correctness. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-18 17:38 ` Warren W. Gay VE3WWG @ 2002-03-19 9:21 ` John McCabe 2002-03-19 17:11 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 79+ messages in thread From: John McCabe @ 2002-03-19 9:21 UTC (permalink / raw) On Mon, 18 Mar 2002 17:38:46 GMT, "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote: >My own personal observation is that C/C++ programmers will err on the >side of efficiency, rather than safety. After a free()/delete, they'll >usually not set the pointer to null. I'd never really thought of it as an efficiency issue but, having used C++ for about 8 months now almost full-time I've got to the stage of pretty much setting all pointers to NULL after a delete, unless they're in a destructor (as it does seem like a waste of time there). Something else about unchecked deallocation, as far as I can remember, is that if you give it a null pointer it doesn't do anything. This is nice (but in a way it can make you lazy :-) ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-19 9:21 ` John McCabe @ 2002-03-19 17:11 ` Warren W. Gay VE3WWG 2002-03-19 17:16 ` Pat Rogers ` (2 more replies) 0 siblings, 3 replies; 79+ messages in thread From: Warren W. Gay VE3WWG @ 2002-03-19 17:11 UTC (permalink / raw) John McCabe wrote: > On Mon, 18 Mar 2002 17:38:46 GMT, "Warren W. Gay VE3WWG" > <ve3wwg@home.com> wrote: > >>My own personal observation is that C/C++ programmers will err on the >>side of efficiency, rather than safety. After a free()/delete, they'll >>usually not set the pointer to null. > > I'd never really thought of it as an efficiency issue but, having used > C++ for about 8 months now almost full-time I've got to the stage of > pretty much setting all pointers to NULL after a delete, unless > they're in a destructor (as it does seem like a waste of time there). > > Something else about unchecked deallocation, as far as I can remember, > is that if you give it a null pointer it doesn't do anything. This is > nice (but in a way it can make you lazy :-) If this is true, this is bad IMHO. I'd rather know by an exception that I was trying to free something that was "no more", than to go glibly forward. I'll have to test this on GNAT sometime. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-19 17:11 ` Warren W. Gay VE3WWG @ 2002-03-19 17:16 ` Pat Rogers 2002-03-19 17:51 ` David C. Hoos 2002-03-19 18:20 ` Frank J. Lhota 2 siblings, 0 replies; 79+ messages in thread From: Pat Rogers @ 2002-03-19 17:16 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message news:3C97713C.1040805@home.com... > John McCabe wrote: <snip> > > Something else about unchecked deallocation, as far as I can remember, > > is that if you give it a null pointer it doesn't do anything. This is > > nice (but in a way it can make you lazy :-) > > If this is true, this is bad IMHO. I'd rather know by an exception > that I was trying to free something that was "no more", than to go > glibly forward. I'll have to test this on GNAT sometime. It is true: RM 13.11.2{8}: 4 Given an instance of Unchecked_Deallocation declared as follows: 5 procedure Free is new Ada.Unchecked_Deallocation( object_subtype_name, access_to_variable_subtype_name); 6 Procedure Free has the following effect: 7 1. After executing Free(X), the value of X is null. 8 2. Free(X), when X is already equal to null, has no effect. --- Patrick Rogers Consulting and Training in: http://www.classwide.com Real-Time/OO Languages progers@classwide.com Hard Deadline Schedulability Analysis (281)648-3165 Software Fault Tolerance ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-19 17:11 ` Warren W. Gay VE3WWG 2002-03-19 17:16 ` Pat Rogers @ 2002-03-19 17:51 ` David C. Hoos 2002-03-19 18:20 ` Frank J. Lhota 2 siblings, 0 replies; 79+ messages in thread From: David C. Hoos @ 2002-03-19 17:51 UTC (permalink / raw) One problem with expecting an exception to be raised is that if the once-freed memory has been re-allocated it's impossible to discern whether an access value was set by the original or by the subsequent allocation. Hence, the desirability of setting access values to null on deallocation. ----- Original Message ----- From: "Warren W. Gay VE3WWG" <ve3wwg@home.com> Newsgroups: comp.lang.ada To: <comp.lang.ada@ada.eu.org> Sent: Tuesday, March 19, 2002 11:11 AM Subject: Re: memory leakages with Ada? > John McCabe wrote: > > > On Mon, 18 Mar 2002 17:38:46 GMT, "Warren W. Gay VE3WWG" > > <ve3wwg@home.com> wrote: > > > >>My own personal observation is that C/C++ programmers will err on the > >>side of efficiency, rather than safety. After a free()/delete, they'll > >>usually not set the pointer to null. > > > > I'd never really thought of it as an efficiency issue but, having used > > C++ for about 8 months now almost full-time I've got to the stage of > > pretty much setting all pointers to NULL after a delete, unless > > they're in a destructor (as it does seem like a waste of time there). > > > > Something else about unchecked deallocation, as far as I can remember, > > is that if you give it a null pointer it doesn't do anything. This is > > nice (but in a way it can make you lazy :-) > > > If this is true, this is bad IMHO. I'd rather know by an exception > > that I was trying to free something that was "no more", than to go > glibly forward. I'll have to test this on GNAT sometime. > -- > Warren W. Gay VE3WWG > http://home.cogeco.ca/~ve3wwg > > _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada > ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-19 17:11 ` Warren W. Gay VE3WWG 2002-03-19 17:16 ` Pat Rogers 2002-03-19 17:51 ` David C. Hoos @ 2002-03-19 18:20 ` Frank J. Lhota 2002-03-19 23:43 ` Mark Johnson 2 siblings, 1 reply; 79+ messages in thread From: Frank J. Lhota @ 2002-03-19 18:20 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message news:3C97713C.1040805@home.com... > > Something else about unchecked deallocation, as far as I can remember, > > is that if you give it a null pointer it doesn't do anything. This is > > nice (but in a way it can make you lazy :-) > > > If this is true, this is bad IMHO. I'd rather know by an exception > > that I was trying to free something that was "no more", than to go > glibly forward. I'll have to test this on GNAT sometime. Yes, it is true that instantiations of Ada.Unchecked_Deallocation are required to do nothing if called with a null access value. This is also true of the C/C++ equivalents, i.e. the C call "free(NULL)" should also do nothing, according to the standard. I'm not sure why this is bad. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-19 18:20 ` Frank J. Lhota @ 2002-03-19 23:43 ` Mark Johnson 2002-03-20 15:09 ` Frank J. Lhota 0 siblings, 1 reply; 79+ messages in thread From: Mark Johnson @ 2002-03-19 23:43 UTC (permalink / raw) "Frank J. Lhota" wrote: > > Yes, it is true that instantiations of Ada.Unchecked_Deallocation are > required to do nothing if called with a null access value. This is also true > of the C/C++ equivalents, i.e. the C call "free(NULL)" should also do > nothing, according to the standard. > > I'm not sure why this is bad. A little history. I have an old copy of K&R (Chapter 8, p 177) and the implementation in that book for alloc/free will blow up if you provide a NULL pointer to free. It is coded something like the following... free(ap) char *ap; { register HEADER *p, *q; p = (HEADER *)ap-1; [at this point, p generally has an invalid address if ap is NULL] There MAY still be some broken implementations using this code sequence .... :-) That is not to say that a general method of... free(p) p = NULL; (or the Ada equivalent) is one way of making your code far more robust than keeping the dangling pointers around. I use a method like that to... o allow for a check for NULL pointers to determine if the data is valid o get an immediate exception when I forget to check & dereference a NULL pointer (many machines) o it prevents a subsequent free to that pointer - a known bad operation on several systems That it has the additional benefit of being a "no operation" to free is a side effect I would just as soon not exercise. --Mark ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-19 23:43 ` Mark Johnson @ 2002-03-20 15:09 ` Frank J. Lhota 0 siblings, 0 replies; 79+ messages in thread From: Frank J. Lhota @ 2002-03-20 15:09 UTC (permalink / raw) "Mark Johnson" <mark_h_johnson@raytheon.com> wrote in message news:3C97CD1F.A675D84F@raytheon.com... > A little history. I have an old copy of K&R (Chapter 8, p 177) and the > implementation in that book for alloc/free will blow up if you provide a > NULL pointer to free. It is coded something like the following... I probably should have been clearer. ANSI C requires that free(NULL) should have no effect. Pre-ANSI compilers may very well have not followed this rule. The whole ANSI C effort has been hobbled by the fact that there was so much C code out there that depended on existing compiler quirks. The standard ended up being fairly toothless, especially in the requirements of the standard library functions. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-17 5:43 ` Kevin Cline 2002-03-17 7:22 ` Chad R. Meiners @ 2002-03-17 7:27 ` Hyman Rosen 2002-03-18 3:52 ` Kevin Cline 1 sibling, 1 reply; 79+ messages in thread From: Hyman Rosen @ 2002-03-17 7:27 UTC (permalink / raw) Kevin Cline wrote: is that it is more easily debugged because the crash is immediate. > Any code that keeps invalid pointers around, whether null or not, is > poorly crafted. You don't terminate your linked lists? ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-17 7:27 ` Hyman Rosen @ 2002-03-18 3:52 ` Kevin Cline 2002-03-18 5:37 ` Hyman Rosen 0 siblings, 1 reply; 79+ messages in thread From: Kevin Cline @ 2002-03-18 3:52 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote in message news:<3C94463A.6040203@mail.com>... > Kevin Cline wrote: > is that it is more easily debugged because the crash is immediate. > > Any code that keeps invalid pointers around, whether null or not, is > > poorly crafted. > > You don't terminate your linked lists? That wasn't really on my mind, since it's been such a long time since I've needed to reimplement the linked list. How many linked list implementations does the world need? ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-18 3:52 ` Kevin Cline @ 2002-03-18 5:37 ` Hyman Rosen 0 siblings, 0 replies; 79+ messages in thread From: Hyman Rosen @ 2002-03-18 5:37 UTC (permalink / raw) Kevin Cline wrote: > That wasn't really on my mind, since it's been such a long time > since I've needed to reimplement the linked list. > How many linked list implementations does the world need? One more :-) GRACE list? ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-14 20:12 ` Marin David Condic 2002-03-15 9:37 ` John McCabe @ 2002-03-15 17:41 ` Kevin Cline 2002-03-15 18:00 ` Marin David Condic 2002-03-15 18:08 ` Hyman Rosen 1 sibling, 2 replies; 79+ messages in thread From: Kevin Cline @ 2002-03-15 17:41 UTC (permalink / raw) "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<a6r075$7ei$1@nh.pace.co.uk>... > 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. > > 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. So dynamic memory allocation is no problem in Ada because "we just don't do that?" That's fine for embedded applications, but the users of desktop applications expect them to consume memory proprotional to the data set size. They aren't too happy with messages like "sorry, file too large, please increase DATA_FILE.MAX_SIZE and recompile." ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 17:41 ` Kevin Cline @ 2002-03-15 18:00 ` Marin David Condic 2002-03-15 18:08 ` Hyman Rosen 1 sibling, 0 replies; 79+ messages in thread From: Marin David Condic @ 2002-03-15 18:00 UTC (permalink / raw) Never said that. Please re-read my prior post and note that I made mention of using dynamic allocation in linked data structures. Sure, when you build a workstation app that deals with some collection of data that varies considerably, you'd put it into a linked list or a map or a tree or whatever that you build from dynamic memory. But generally that limits the creation & destruction of memory chunks to some limited portion of the code - hopefully a library that you are reusing over and over so it has become reliable with respect to not losing memory. What you typically don't do in Ada that gets done over and over again in C is to dynamically allocate memory every time you need a variable sized string or record that you want to pass around to subprograms. Nor do you typically build libraries that create dynamic data for the caller that the caller is responsible for deallocating. Nor do you typically create pointers to everything in sight to hand off to different parts of a program because parameter passing, function returns, scope/visibility rules, etc. decrease the need to be handing out the address of something to everyone who thinks they want it. Of course Ada programs *do* dynamically allocate memory, but it just isn't as common as it is in C. Hence leaks are less likely. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Kevin Cline" <kcline@optelnow.net> wrote in message news:dcfe911f.0203150941.5ebbb85b@posting.google.com... > > So dynamic memory allocation is no problem in Ada because "we just don't > do that?" That's fine for embedded applications, but the users of desktop > applications expect them to consume memory proprotional to the data > set size. They aren't too happy with messages like "sorry, file too large, > please increase DATA_FILE.MAX_SIZE and recompile." ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 17:41 ` Kevin Cline 2002-03-15 18:00 ` Marin David Condic @ 2002-03-15 18:08 ` Hyman Rosen 2002-03-16 10:15 ` Kevin Cline 1 sibling, 1 reply; 79+ messages in thread From: Hyman Rosen @ 2002-03-15 18:08 UTC (permalink / raw) Kevin Cline wrote: > So dynamic memory allocation is no problem in Ada because "we just don't > do that?" That's fine for embedded applications, but the users of desktop > applications expect them to consume memory proprotional to the data > set size. They aren't too happy with messages like "sorry, file too large, > please increase DATA_FILE.MAX_SIZE and recompile." That's not what he said. In Ada you can declare arrays whose size depends on expressions evaluated at runtime, whereas in C89/C++ (but not C99) array sizes must be constant expressions. Therefore situations which call for buffers whose size depends on some external value can be handled cleanly in Ada by just reading that external value and using it to declare an array whose size depends on it. If you actually need to store these variably-sized objects then of course you will need dynamic allocation, but often you just need to read an object, process it, and dispose of it, and then you can sometimes avoid the allocation. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 18:08 ` Hyman Rosen @ 2002-03-16 10:15 ` Kevin Cline 0 siblings, 0 replies; 79+ messages in thread From: Kevin Cline @ 2002-03-16 10:15 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote in message news:<3C9238A5.7060700@mail.com>... > Kevin Cline wrote: > > So dynamic memory allocation is no problem in Ada because "we just don't > > do that?" That's fine for embedded applications, but the users of desktop > > applications expect them to consume memory proprotional to the data > > set size. They aren't too happy with messages like "sorry, file too large, > > please increase DATA_FILE.MAX_SIZE and recompile." > > That's not what he said. In Ada you can declare arrays whose size > depends on expressions evaluated at runtime, whereas in C89/C++ > (but not C99) array sizes must be constant expressions. Therefore > situations which call for buffers whose size depends on some > external value can be handled cleanly in Ada by just reading that > external value and using it to declare an array whose size depends > on it. A halfway-decent C++ programmer would never use an dynamically allocated array for this purpose. He would use std::vector or std::string. Internally this will result in a heap allocation and deallocation, but that's no problem unless you're stuck with a pathologically bad allocator. > If you actually need to store these variably-sized objects > then of course you will need dynamic allocation... Exactly my point, together with the observation that a great many applications do have this need. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-14 14:07 memory leakages with Ada? Calvin Ow 2002-03-14 14:31 ` Larry Kilgallen 2002-03-14 20:12 ` Marin David Condic @ 2002-03-14 23:14 ` Kevin Cline 2002-03-15 3:20 ` Steve Doiel 2002-03-15 9:27 ` John McCabe 4 siblings, 0 replies; 79+ messages in thread From: Kevin Cline @ 2002-03-14 23:14 UTC (permalink / raw) "Calvin Ow" <calvow@cyberway.com.sg> wrote in message news:<3c90af1e@news.starhub.net.sg>... > Hi, > Has Ada got any memory leakage problems like that of C? In a way, but it's much more like C++ than C. See http://www.it.bton.ac.uk/staff/je/adacraft/ch16.htm. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-14 14:07 memory leakages with Ada? Calvin Ow ` (2 preceding siblings ...) 2002-03-14 23:14 ` Kevin Cline @ 2002-03-15 3:20 ` Steve Doiel 2002-03-15 9:32 ` John McCabe ` (2 more replies) 2002-03-15 9:27 ` John McCabe 4 siblings, 3 replies; 79+ messages in thread From: Steve Doiel @ 2002-03-15 3:20 UTC (permalink / raw) "Calvin Ow" <calvow@cyberway.com.sg> wrote in message news:3c90af1e@news.starhub.net.sg... > Hi, > Has Ada got any memory leakage problems like that of C? > Especially with the use of Pragma calls to C? > I'll assume you read the other replies to your post. I would like to add that there are many cases in Ada where you don't need to use dynamic allocation when you would have to use dynamic allocation in C. For example, if you want to read a block of data that is preceded by a count that gives the amount of data, in Ada the code would be something like: nbBytes := GetNbBytes( dataSource ); declare dataBuffer : ByteBuffer( 1 .. nbBytes ); begin GetData( dataBuffer ); end; Where in C the code would look something like: nbBytes = GetNbBytes( dataSource ); dataPtr = (char *)calloc( nbBytes ); GetData( dataPtr ); free( dataPtr ); Disclaimer: I didn't compile either of the above code snippets above, and I seldom release memory I dynamically allocate in C (I usually allocate once and re-use for the life of the program for real-time systems), but you get the idea. With regard to the Pragma calls to C, in some cases you can use a buffer declared on the stack instead of dynamically allocating for that case as well, but when you can't I don't think you'll find Ada to be less succeptable to leaks. SteveD ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 3:20 ` Steve Doiel @ 2002-03-15 9:32 ` John McCabe 2002-03-15 15:46 ` Hyman Rosen 2002-03-15 17:29 ` Kevin Cline 2002-03-15 15:48 ` Jeffrey Carter 2002-03-15 17:25 ` Kevin Cline 2 siblings, 2 replies; 79+ messages in thread From: John McCabe @ 2002-03-15 9:32 UTC (permalink / raw) On Fri, 15 Mar 2002 03:20:52 GMT, "Steve Doiel" <nospam_steved94@attbi.com> wrote: > nbBytes := GetNbBytes( dataSource ); > declare > dataBuffer : ByteBuffer( 1 .. nbBytes ); > begin > GetData( dataBuffer ); > end; > >Where in C the code would look something like: > > nbBytes = GetNbBytes( dataSource ); > dataPtr = (char *)calloc( nbBytes ); > GetData( dataPtr ); > free( dataPtr ); What's wrong with: nbBytes = GetNbBytes (dataSource); { char data[nbBytes]; GetData(data); } ? ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 9:32 ` John McCabe @ 2002-03-15 15:46 ` Hyman Rosen 2002-03-15 17:29 ` Kevin Cline 1 sibling, 0 replies; 79+ messages in thread From: Hyman Rosen @ 2002-03-15 15:46 UTC (permalink / raw) John McCabe wrote: > What's wrong with: > nbBytes = GetNbBytes (dataSource); > { > char data[nbBytes]; > GetData(data); > } That's C99. Until that revision, C arrays could be decalred only with constant-expression sizes. And there are as yet few compilers around which implement C99. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 9:32 ` John McCabe 2002-03-15 15:46 ` Hyman Rosen @ 2002-03-15 17:29 ` Kevin Cline 1 sibling, 0 replies; 79+ messages in thread From: Kevin Cline @ 2002-03-15 17:29 UTC (permalink / raw) john.mccabe@emrad.ns.com (John McCabe) wrote in message news:<3c91bf44.1892100@news.demon.co.uk>... > On Fri, 15 Mar 2002 03:20:52 GMT, "Steve Doiel" > <nospam_steved94@attbi.com> wrote: > > > nbBytes := GetNbBytes( dataSource ); > > declare > > dataBuffer : ByteBuffer( 1 .. nbBytes ); > > begin > > GetData( dataBuffer ); > > end; > > > >Where in C the code would look something like: > > > > nbBytes = GetNbBytes( dataSource ); > > dataPtr = (char *)calloc( nbBytes ); > > GetData( dataPtr ); > > free( dataPtr ); > > What's wrong with: > > nbBytes = GetNbBytes (dataSource); > { > char data[nbBytes]; This wasn't legal until C99, and is still not legal in C++. > GetData(data); > } > > ? ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 3:20 ` Steve Doiel 2002-03-15 9:32 ` John McCabe @ 2002-03-15 15:48 ` Jeffrey Carter 2002-03-16 3:05 ` Steve Doiel 2002-03-15 17:25 ` Kevin Cline 2 siblings, 1 reply; 79+ messages in thread From: Jeffrey Carter @ 2002-03-15 15:48 UTC (permalink / raw) Steve Doiel wrote: > > For example, if you want to read a block of data that is preceded by a count > that gives the amount of data, in Ada the code would be something like: > > nbBytes := GetNbBytes( dataSource ); > declare > dataBuffer : ByteBuffer( 1 .. nbBytes ); > begin > GetData( dataBuffer ); > end; No, Ada looks little like this. It looks much better: Num_Bytes := Get_Count (Data_Source); Read_Data : declare Data_Buffer : Byte_List (1 .. Num_Bytes); begin -- Read_Data Get_Data (Data => Data_Buffer); ... end Read_Data; -- Jeffrey Carter ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 15:48 ` Jeffrey Carter @ 2002-03-16 3:05 ` Steve Doiel 2002-03-16 20:19 ` Jeffrey Carter 0 siblings, 1 reply; 79+ messages in thread From: Steve Doiel @ 2002-03-16 3:05 UTC (permalink / raw) "Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message news:3C9217EB.B74EDFC2@boeing.com... > No, Ada looks little like this. It looks much better: > > Num_Bytes := Get_Count (Data_Source); > > Read_Data : declare > Data_Buffer : Byte_List (1 .. Num_Bytes); > begin -- Read_Data > Get_Data (Data => Data_Buffer); > ... > end Read_Data; > Let's NOT start another garbage thread on coding conventions. > -- > Jeffrey Carter ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-16 3:05 ` Steve Doiel @ 2002-03-16 20:19 ` Jeffrey Carter 0 siblings, 0 replies; 79+ messages in thread From: Jeffrey Carter @ 2002-03-16 20:19 UTC (permalink / raw) Steve Doiel wrote: > > Let's NOT start another garbage thread on coding conventions. Why not? This is already a garbage thread on "Ada is better than C/++". -- Jeff Carter "Your mother was a hamster and your father smelt of elderberries." Monty Python & the Holy Grail ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 3:20 ` Steve Doiel 2002-03-15 9:32 ` John McCabe 2002-03-15 15:48 ` Jeffrey Carter @ 2002-03-15 17:25 ` Kevin Cline 2002-03-15 18:03 ` Hyman Rosen 2 siblings, 1 reply; 79+ messages in thread From: Kevin Cline @ 2002-03-15 17:25 UTC (permalink / raw) "Steve Doiel" <nospam_steved94@attbi.com> wrote in message news:<oMdk8.35751$702.15618@sccrnsc02>... > "Calvin Ow" <calvow@cyberway.com.sg> wrote in message > news:3c90af1e@news.starhub.net.sg... > > Hi, > > Has Ada got any memory leakage problems like that of C? > > Especially with the use of Pragma calls to C? > > > > I'll assume you read the other replies to your post. > > I would like to add that there are many cases in Ada where you don't need to > use dynamic allocation when you would have to use dynamic allocation in C. > > For example, if you want to read a block of data that is preceded by a count > that gives the amount of data, in Ada the code would be something like: > > nbBytes := GetNbBytes( dataSource ); > declare > dataBuffer : ByteBuffer( 1 .. nbBytes ); > begin > GetData( dataBuffer ); > end; > > Where in C the code would look something like: > > nbBytes = GetNbBytes( dataSource ); > dataPtr = (char *)calloc( nbBytes ); > GetData( dataPtr ); > free( dataPtr ); No problem in C++ though: nbBytes = GetNbBytes( dataSource ); std::vector<char> data(nbBytes); GetData( data ); ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 17:25 ` Kevin Cline @ 2002-03-15 18:03 ` Hyman Rosen 2002-03-16 10:07 ` Kevin Cline 0 siblings, 1 reply; 79+ messages in thread From: Hyman Rosen @ 2002-03-15 18:03 UTC (permalink / raw) Kevin Cline wrote: > No problem in C++ though: > nbBytes = GetNbBytes( dataSource ); > std::vector<char> data(nbBytes); > GetData( data ); But this is identical in spirit to the C version, in that memory will be allocated from the heap instead of the stack. The Ada version requires no deallocation or destruction other than that afforded by exiting the scope of the object. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-15 18:03 ` Hyman Rosen @ 2002-03-16 10:07 ` Kevin Cline 2002-03-17 3:00 ` Hyman Rosen 0 siblings, 1 reply; 79+ messages in thread From: Kevin Cline @ 2002-03-16 10:07 UTC (permalink / raw) Hyman Rosen <hyrosen@mail.com> wrote in message news:<3C923755.7050007@mail.com>... > Kevin Cline wrote: > > No problem in C++ though: > > nbBytes = GetNbBytes( dataSource ); > > std::vector<char> data(nbBytes); > > GetData( data ); > > But this is identical in spirit to the C version, > in that memory will be allocated from the heap > instead of the stack. The Ada version requires > no deallocation or destruction other than that > afforded by exiting the scope of the object. It's not at all like the C version. The memory is managed by std::vector, and will be deallocated in the vector destructor when the scope is exited. In a well-written C++ (or Ada) program all memory allocation and deallocation will be handled by low-level classes. Explicit calls to allocate or deallocate memory should never appear in higher-level code. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-16 10:07 ` Kevin Cline @ 2002-03-17 3:00 ` Hyman Rosen 0 siblings, 0 replies; 79+ messages in thread From: Hyman Rosen @ 2002-03-17 3:00 UTC (permalink / raw) Kevin Cline wrote: > It's not at all like the C version. > The memory is managed by std::vector, and will be > deallocated in the vector destructor when the scope is exited. But the memory will come from the heap instead of the stack. This has speed and memory implications which are absent from the Ada version. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-14 14:07 memory leakages with Ada? Calvin Ow ` (3 preceding siblings ...) 2002-03-15 3:20 ` Steve Doiel @ 2002-03-15 9:27 ` John McCabe 4 siblings, 0 replies; 79+ messages in thread From: John McCabe @ 2002-03-15 9:27 UTC (permalink / raw) On Thu, 14 Mar 2002 22:07:13 +0800, "Calvin Ow" <calvow@cyberway.com.sg> wrote: >Hi, >Has Ada got any memory leakage problems like that of C? >Especially with the use of Pragma calls to C? Ada *shouldn't* have any inherent memory leaks, just like most languages shouldn't. Any memory leaks there are ones you've put in yourself (perhaps because you've mismanaged calls to C library functions that allocate memory etc. It is just as easy in Ada to create memory leaks as it is in C/C++. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada?
@ 2002-03-20 6:25 Christoph Grein
2002-03-20 16:35 ` Hyman Rosen
0 siblings, 1 reply; 79+ messages in thread
From: Christoph Grein @ 2002-03-20 6:25 UTC (permalink / raw)
> Yes, that's exactly what I was trying to say!
> My point was that in the various C techniques,
> the bytes of the result get constructed once,
> and then don't have to be copied as part of
> the function return, whereas returning a String
> in Ada will involve copying the bytes.
declare
Result_1: String := function_Call;
Result_2: String renames function_Call;
Result_1 is a copy of the bytes, Result_2 is not.
Note the second is an Ada95 feature. In Ada83, function calls were not objects
(and thus could not be renamed).
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: memory leakages with Ada? 2002-03-20 6:25 Christoph Grein @ 2002-03-20 16:35 ` Hyman Rosen 0 siblings, 0 replies; 79+ messages in thread From: Hyman Rosen @ 2002-03-20 16:35 UTC (permalink / raw) Christoph Grein wrote: > declare > Result_1: String := function_Call; > Result_2: String renames function_Call; > > Result_1 is a copy of the bytes, Result_2 is not. Why would you think so? Where does function_Call put its result? ^ permalink raw reply [flat|nested] 79+ messages in thread
end of thread, other threads:[~2002-03-22 5:10 UTC | newest] Thread overview: 79+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-03-14 14:07 memory leakages with Ada? Calvin Ow 2002-03-14 14:31 ` Larry Kilgallen 2002-03-14 20:42 ` Nick Roberts 2002-03-14 21:11 ` Larry Kilgallen 2002-03-14 21:07 ` Anh_Vo 2002-03-14 20:12 ` Marin David Condic 2002-03-15 9:37 ` John McCabe 2002-03-15 12:55 ` Pat Rogers 2002-03-16 4:36 ` Will 2002-03-16 4:53 ` Pat Rogers 2002-03-16 12:21 ` Larry Kilgallen 2002-03-16 9:13 ` DPH 2002-03-16 14:38 ` Pat Rogers 2002-03-16 14:56 ` DPH 2002-03-16 15:51 ` Preben Randhol 2002-03-16 16:39 ` DPH 2002-03-16 19:51 ` Pat Rogers 2002-03-16 20:40 ` DPH 2002-03-17 19:31 ` Richard Riehle 2002-03-17 21:49 ` Pat Rogers 2002-03-17 22:02 ` Pat Rogers 2002-03-18 22:32 ` Randy Brukardt 2002-03-18 22:47 ` Pat Rogers 2002-03-18 7:22 ` Richard Riehle 2002-03-18 17:35 ` Marin David Condic 2002-03-17 16:26 ` Steve Doiel 2002-03-16 20:18 ` Robert A Duff 2002-03-16 20:36 ` DPH 2002-03-15 14:20 ` Marin David Condic 2002-03-18 17:54 ` Warren W. Gay VE3WWG 2002-03-18 19:54 ` Hyman Rosen 2002-03-18 20:34 ` Larry Kilgallen 2002-03-18 21:18 ` Hyman Rosen 2002-03-18 21:45 ` Larry Kilgallen 2002-03-20 1:19 ` Hyman Rosen 2002-03-20 17:06 ` Warren W. Gay VE3WWG 2002-03-20 17:56 ` Larry Kilgallen 2002-03-20 17:48 ` Marin David Condic 2002-03-22 0:25 ` Matthew Woodcraft 2002-03-22 5:10 ` Hyman Rosen 2002-03-18 22:18 ` Marin David Condic 2002-03-20 20:49 ` Bertrand Augereau 2002-03-21 4:31 ` Will 2002-03-15 16:00 ` Hyman Rosen 2002-03-15 21:59 ` Chad R. Meiners 2002-03-17 5:43 ` Kevin Cline 2002-03-17 7:22 ` Chad R. Meiners 2002-03-18 4:09 ` Kevin Cline 2002-03-18 16:54 ` Chad R. Meiners 2002-03-18 17:38 ` Warren W. Gay VE3WWG 2002-03-19 9:21 ` John McCabe 2002-03-19 17:11 ` Warren W. Gay VE3WWG 2002-03-19 17:16 ` Pat Rogers 2002-03-19 17:51 ` David C. Hoos 2002-03-19 18:20 ` Frank J. Lhota 2002-03-19 23:43 ` Mark Johnson 2002-03-20 15:09 ` Frank J. Lhota 2002-03-17 7:27 ` Hyman Rosen 2002-03-18 3:52 ` Kevin Cline 2002-03-18 5:37 ` Hyman Rosen 2002-03-15 17:41 ` Kevin Cline 2002-03-15 18:00 ` Marin David Condic 2002-03-15 18:08 ` Hyman Rosen 2002-03-16 10:15 ` Kevin Cline 2002-03-14 23:14 ` Kevin Cline 2002-03-15 3:20 ` Steve Doiel 2002-03-15 9:32 ` John McCabe 2002-03-15 15:46 ` Hyman Rosen 2002-03-15 17:29 ` Kevin Cline 2002-03-15 15:48 ` Jeffrey Carter 2002-03-16 3:05 ` Steve Doiel 2002-03-16 20:19 ` Jeffrey Carter 2002-03-15 17:25 ` Kevin Cline 2002-03-15 18:03 ` Hyman Rosen 2002-03-16 10:07 ` Kevin Cline 2002-03-17 3:00 ` Hyman Rosen 2002-03-15 9:27 ` John McCabe -- strict thread matches above, loose matches on Subject: below -- 2002-03-20 6:25 Christoph Grein 2002-03-20 16:35 ` Hyman Rosen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox