memory leakages with Ada?

memory leakages with Ada?

[Calvin Ow]

Hi,
Has Ada got any memory leakage problems like that of C?
Especially with the use of Pragma calls to C?

Re: memory leakages with Ada?

[Larry Kilgallen]

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.

Re: memory leakages with Ada?

[Marin David Condic]

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

Re: memory leakages with Ada?

[Nick Roberts]

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.

Re: memory leakages with Ada?

[Anh_Vo]

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.

Re: memory leakages with Ada?

[Larry Kilgallen]

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

Re: memory leakages with Ada?

[Kevin Cline]

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

Re: memory leakages with Ada?

[Steve Doiel]

"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

Re: memory leakages with Ada?

[John McCabe]

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

Re: memory leakages with Ada?

[John McCabe]

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

?

Re: memory leakages with Ada?

[John McCabe]

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

Re: memory leakages with Ada?

[Pat Rogers]

"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

Re: memory leakages with Ada?

[Marin David Condic]

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

Re: memory leakages with Ada?

[Hyman Rosen]

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.

Re: memory leakages with Ada?

[Jeffrey Carter]

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

Re: memory leakages with Ada?

[Hyman Rosen]

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.

Re: memory leakages with Ada?

[Kevin Cline]

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

Re: memory leakages with Ada?

[Kevin Cline]

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);
> }
> 
> ?

Re: memory leakages with Ada?

[Kevin Cline]

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

Re: memory leakages with Ada?

[Marin David Condic]

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

Re: memory leakages with Ada?

[Hyman Rosen]

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.

Re: memory leakages with Ada?

[Hyman Rosen]

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.

Re: memory leakages with Ada?

[Chad R. Meiners]

"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

Re: memory leakages with Ada?

[Steve Doiel]

"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

Re: memory leakages with Ada?

[Will]

"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 :)

Re: memory leakages with Ada?

[Pat Rogers]

"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 :)

:-)

Re: memory leakages with Ada?

[DPH]

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

Re: memory leakages with Ada?

[Kevin Cline]

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.

Re: memory leakages with Ada?

[Kevin Cline]

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.

Re: memory leakages with Ada?

[Larry Kilgallen]

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.

Re: memory leakages with Ada?

[Pat Rogers]

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

Re: memory leakages with Ada?

[DPH]

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

Re: memory leakages with Ada?

[Preben Randhol]

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

Re: memory leakages with Ada?

[DPH]

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

Re: memory leakages with Ada?

[Pat Rogers]

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

Re: memory leakages with Ada?

[Robert A Duff]

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

Re: memory leakages with Ada?

[Jeffrey Carter]

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

Re: memory leakages with Ada?

[DPH]

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 

Re: memory leakages with Ada?

[DPH]

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

Re: memory leakages with Ada?

[Hyman Rosen]

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.

Re: memory leakages with Ada?

[Kevin Cline]

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

Re: memory leakages with Ada?

[Chad R. Meiners]

"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

Re: memory leakages with Ada?

[Hyman Rosen]

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?

Re: memory leakages with Ada?

[Steve Doiel]

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

Re: memory leakages with Ada?

[Richard Riehle]

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

Re: memory leakages with Ada?

[Pat Rogers]

"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

Re: memory leakages with Ada?

[Pat Rogers]

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.

Re: memory leakages with Ada?

[Kevin Cline]

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?

Re: memory leakages with Ada?

[Kevin Cline]

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

Re: memory leakages with Ada?

[Hyman Rosen]

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?

Re: memory leakages with Ada?

[Richard Riehle]

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

Re: memory leakages with Ada?

[Chad R. Meiners]

"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

Re: memory leakages with Ada?

[Marin David Condic]

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.

Re: memory leakages with Ada?

[Warren W. Gay VE3WWG]

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

Re: memory leakages with Ada?

[Warren W. Gay VE3WWG]

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

Re: memory leakages with Ada?

[Hyman Rosen]

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.

Re: memory leakages with Ada?

[Larry Kilgallen]

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.

Re: memory leakages with Ada?

[Hyman Rosen]

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.

Re: memory leakages with Ada?

[Larry Kilgallen]

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.

Re: memory leakages with Ada?

[Marin David Condic]

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

Re: memory leakages with Ada?

[Randy Brukardt]

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

Re: memory leakages with Ada?

[Pat Rogers]

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

Re: memory leakages with Ada?

[John McCabe]

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 :-)

Re: memory leakages with Ada?

[Warren W. Gay VE3WWG]

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

Re: memory leakages with Ada?

[Pat Rogers]

"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

Re: memory leakages with Ada?

[David C. Hoos]

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
>

Re: memory leakages with Ada?

[Frank J. Lhota]

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

Re: memory leakages with Ada?

[Mark Johnson]

"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

Re: memory leakages with Ada?

[Hyman Rosen]

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.

Re: memory leakages with Ada?

[Christoph Grein]

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

Re: memory leakages with Ada?

[Frank J. Lhota]

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

Re: memory leakages with Ada?

[Hyman Rosen]

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?

Re: memory leakages with Ada?

[Warren W. Gay VE3WWG]

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

Re: memory leakages with Ada?

[Marin David Condic]

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

Re: memory leakages with Ada?

[Larry Kilgallen]

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.

Re: memory leakages with Ada?

[Bertrand Augereau]

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

Re: memory leakages with Ada?

[Will]

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

Re: memory leakages with Ada?

[Matthew Woodcraft]

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-

Re: memory leakages with Ada?

[Hyman Rosen]

Matthew Woodcraft wrote:
> See the keep_stack_depressed() function.

I see. Turns any function into an alloca() variant.