Re: newbie: can't read fast enough... :-) memory leaks...

[Brad Moore <brad.moore@shaw.ca>]

On 2014-09-03 4:17 AM, Pascal Obry wrote:
> Le mercredi 03 septembre 2014 à 02:38 -0700, gdotone@gmail.com a
> écrit :
>> i know i'll get there, currently in chapter 3, of Ada 95 PSPD, anyway, can Ada code have/produce memory leaks?  well, maybe not "can" it but, does Ada, natively prevent memory leaks?
>>
>> like, C seems to leak all over the place, if not managed correctly by the programmer.
>
> This depends on the implementation. Ada make it possible to use a
> garbage collector but as far as I know no implementation is using one.
> So yes, every Ada compiler around will leak memory if not properly
> freed.
>
> To free an allocated object one need to instantiate
> Ada.Unchecked_Deallocation.
>
> Note that well designed object can deallocate themselves when possible
> by using Ada.Finalization API. As an example, Unbounded_String are using
> dynamic allocation but you need need to worry about that as a user.
>

A couple of points on heap allocation that I think newcomers to Ada 
often miss, or fail to appreciate.

Compared to languages like C and C++, I would say Ada reduces the need 
for heap allocation.

For example, In C, for a function that can return a string of variable 
length, a common approach is to allocate memory for the result from the 
heap, and then return the address of the allocated result to the caller, 
since in C, functions essentially return numeric values.
A numeric value might be a char, int, float, or an address of some type.

eg.

char * get_string()
{
    const char *s1 = "The return result";
    char * ptr = malloc(strlen(S1) + 1);
    strcpy(ptr, s1);
    return ptr;
}

or alternatively, pass the address of the buffer as a parameter into the 
function as in...

void get_string(char *buf, int buflen)
{
    const char *s1 = "The return result";
    if (strlen(s1) + 1 > buflen) {
       FATAL_ERR("Buffer too small");
    }
    strcpy(buf, s1);
}

But this relies on the caller knowing the maximum length of the result 
before making the call.

In Ada, unconstrained types such as string types and arrays can be 
easily returned on the stack as a result without allocating from the heap.

eg.

function Get_String return String is
begin
   return "The return result";
end Get_String;

The second point is that another alternative to calling 
Unchecked_Deallocation is to let the finalization of an access type free 
all heap allocations for that type, using a nested scope.

eg.
      declare
         type String_Access is access String;
         A, B : String_Access;
      begin
         A := new String'("String 1");
         B := new String'("String 2");
         ... -- Operate on the data.
      end;
      -- A and B are automatically freed here because the String_Access
      -- is finalized since the scope of the declaration of the access
      -- type is being exited, and finalizing an access type also
      -- finalizes its collection (allocated objects designated by that
      -- type).

This is a nice way to free up a bunch of objects that are no longer 
needed, if it can be guaranteed that the objects are only needed in a 
nested scope. I like this better than garbage collection, because the
deallocation occurs more consistently, when and where it is needed.
I view this as being less error prone, if one is able to take advantage 
of this approach.

There are other techniques and libraries that are helpful in this area,
but I think these two points are a good starting point.

Brad