From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6b3a3c920575b35a X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 28 Jul 2006 16:26:41 -0500 Date: Fri, 28 Jul 2006 17:14:40 -0400 From: Jeffrey Creem User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: How to pass two dimensional arrays to C References: <1154084819.088112.325730@p79g2000cwp.googlegroups.com> <1154119563.642347.13670@b28g2000cwb.googlegroups.com> In-Reply-To: <1154119563.642347.13670@b28g2000cwb.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.147.74.171 X-Trace: sv3-rtHlcn6XcW846NF/uG2FPrN2qtOdbgxc+ilhpriu3tne4GfGOAMh9Pql6u7P5LOwcZ3UIpaYbSYnMk4!Mg5Rp+T10NVh+gqWycyjt3jH5EtkIoDRFjEGVlkwRE+Qu249M+fv3jIoqzMNlG0mi/MgiwDiTv01!mPI= X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news2.google.com comp.lang.ada:6003 Date: 2006-07-28T17:14:40-04:00 List-Id: 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.