Re: Thick bindings to a C library and gnattest: suggestions?

[Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org>]

On 07/01/2013 02:02 AM, ziotom78@gmail.com wrote:
>
> First question: the vectors used by the CFITSIO library are sometimes
> huge (millions of elements), sometimes very small (~ 10 elements).
> I decided to always allocate them on the heap, using declarations like
> these:
>
>     subtype Double is Interfaces.C.double;
>     type Double_Array is array (Positive range <>)
>       of Interfaces.C.double;
>     pragma Convention (C, Double_Array);
>     type Double_Array_Ptr is access Double_Array;
>
> (similar declarations exist for arrays of integers/long...), and then
> using "new Double_Array" whenever I need to allocate room for an
> array. Every binding function only uses Double_Array_Ptr. Is this the best
> way to do this in Ada? Every text I read about Ada says to stay away
> from objects allocated on the heap, but I do not see any other
> solution here.

One should not use heap allocation unnecessarily, as it requires memory 
management, which is often complex and error prone, but that does not mean one 
should never use heap allocation. When it is necessary, there is no alternative. 
What one should not do is have visible access types in public package specs.

As others have pointed out, generally the application is what knows the sizes of 
the objects it works on, and that decides whether heap allocation is required.

I would not use "_Array" in type names. We know it's an array because the type 
declaration says so. The type name should indicate its intended meaning or use, 
not its implementation.

Another approach not mentioned is the use of Ada.Containers.Vectors. This 
implements unbounded arrays. Internally, the arrays are allocated on the heap 
and memory managed, but this complication is hidden from the user. Ada 12 
provides the ability to use them like an array (use of those features currently 
limits you to a single compiler, though).

(Aside: in a world in which GB of RAM are common, it seems odd for a language to 
require explicit heap allocation, and the associated memory management, for 
objects that fit in memory, but not in the stack. Surely it would be better for 
the language to allow the developer to simply declare the object, and for the 
compiler to decide where it will fit, and allocate it and manage its memory 
appropriately. A means to disable automatic heap allocation would be needed for 
systems that disallow heap allocation.)

-- 
Jeff Carter
"Hold your temper. Count ten.... Now let 'er go.
You got a good aim."
Never Give a Sucker an Even Break
105