Re: How to pass two dimensional arrays to C

[Jeffrey Creem <jeff@thecreems.com>]

Jerry wrote:
> Thanks for everyone's comments. I have thin bindings to PLplot nearly
> complete except for this nagging 2D array thing. (I also have a partial
> thick binding plus some easy-to-use one-line plotters as well.)
> 
> I understand how C passes arrays and for 1D arrays and I have relied on
> GNAT's near-universal use of C calling conventions--I think that this
> limits portability to other Ada compilers but "walk before you run"
> seems apropos here since I'm learning Ada and bits of C as I go along.
> I may later use Interfaces.C if there is sufficient interest.
> 
> I have relied on these excerpts from the usual references:
> 
>>From the GNAT User's Guide, Calling Conventions: "C. Data will be
> passed according to the conventions described in section B.3 of the Ada
> 95 Reference Manual."
> 
>>From RM B.3: "An Ada parameter of an array type with component type T,
> of any mode, is passed as a t* argument to a C function, where t is the
> C type corresponding to the Ada type T."
> 
>>From the GNAT Reference Manual section 10.1: Ada scalar types match C
> scalar types. Also, "Ada arrays map directly to C arrays." There is no
> mention of 2D arrays specifically.
> 
> So I'm thinking that GNAT's calling conventions work for only 1D arrays
> and that I'll have to figure out how to convert my 2D z array of
> PL_Float_Array_2D into an array of pointers each pointing to a row
> (column?) of z. I would want to do this without having to bother the
> user with defining his 2D array as a 1D array of 1D arrays.
> 
> It seems that I "should" be able to simply pass a pointer (access
> variable) to the first location of z, that is, a pointer to
> (z'First(1), z'First(2), but I don't see how this could work if C in
> fact sees an array of pointers. Wouldn't C's representation of the
> array z M x N be, say, M pointers each pointing to the address of the
> first element of its M rows? But this would require (M+1)N storage
> locations which seems wrong. I would expect that C would simply expect
> a blob of MN units of memory where each unit is the sizeof(int) and
> rely on M and N being passed as parameters to parse it up correctly.
> 


If C did actually handle real 2d arrays that way, you would be fine but 
you also would not have segfaulted.

This is going to be a pain if you simultaneously want to
1) Keep it a thin binding.
2) Not bother the user with the arrays of pointers to arrays issue
3) Don't want to make the binding horribly inefficient by having to 
create a copy of the data into the C format expected by pl_plot.

I'd probably (in the thin binding) fully expose the ugliness of the 
interface. Not sure you really can avoid it without making a mess..

There are probably a few ways to deal with the thick portion of the 
binding. (e.g. Create a controlled type that hids the array of pointers 
to arrays details and allows the user to resize at will and autocleanup 
storage but keeps the data in something close to what pl_plot expects.

The issue will then be how you let the user access the data. You could 
build cell accessor functions that again hide the details. I've done 
stuff like that but again you do end up with a hit as far as efficiency 
because even with unlining, I am not sure the compiler will be smart 
enough to do strength reduction optimizations on accesses to the 
underlying data in loops. (Could be wrong of course).

Also, the user might want to "see" the data in a more general format 
than the accessors will allow.


I've never really found a solution for this particular style of problem 
that I have been totally happy with. I usually end up with some sort of 
ugly hybrid with a controlled type and a way to access the data in bulk 
as well that requires exposing the details a bit to the user.

It may be that getting worried about efficiency in for this particular 
library might not be worth it but almost any 2d image style library that 
  is designed for heavy use ends up being a resource hog.