Re: C array to Ada pointer to unconstrained array without copying memory

["Steve Adams" <s.adams_s_p_a_m_217@_s_p_a_m_ntlworld.csopam>]

Duncan,
  I have had to do this for my project. What I do is not portable really but
in general is OK if no other solution is available.

Gnat does indeed use Fat pointers. *By Default*
You can make it use thin pointers though:

type var_arr is array (positive range <>) of T;
type var_arr_ptr is access var_arr;
for var_arr_ptr'size use DWORD; -- from memory, probably want a 'size of int
or something

The var_arr_ptr will only be a standard platform pointer size, 32 bits for
ease in the rest of discussion.
The pointer in *GNAT* points to the data (satisfies LRM that arr'access
points to data) and immediately before this are
the bounds, two ints every case i have for 1D arrays, lower then upper ->

[l bound][u bound][data....]

You need to do some pointer manipulations in C when first allocating them to
set the bounds, but Gnat just treats the arrays as normal.
Gnat is good like this since it means that C pointer is handled the same as
Ada pointer.

ObjectAda however has the access value pointing to the bounds, this gives me
quite a few headaches in my work, but gnat has a problem with the calling
convention I need and doesn't handle discriminants properly with the
convention.

For function calls the array can be passed as:
f( pa : in var_arr_ptr) -- reference, NOTE that it is NOT in out, since that
would be a pointer to a pointer
f( pa : in out var_arr) -- behind the scenes reference passed because of
access parameters.

Usual caveats apply that Gnat might change this scheme, however its unlikly.

For infomration the Fat pointer is a struct with two pointers, one to the
bounds and one to the data. Surprise is that the layout of the bounds and
data in memory is the same, so they are allocated in a single call, this
means thin and fat are the same at the basest level, you just have more
overhead for fats.

before language lawyers attack, my project uses intermixed Ada, Fortran,
C/C++ and Pascal. You end up sacrificing portability if you want it to work,
in C this isn't a problem, a single code base manipulated via the
preprocessor is easy, as does fortran. Ada doesn't which makes life hard. I
wish theyed make preprocessing a feature.

Steve A


"Duncan Sands" <baldrick@free.fr> wrote in message
news:mailman.37.1065537708.25614.comp.lang.ada@ada-france.org...
> Greetings.  Given a C pointer Ptr to a type T (which points to a block of
memory
> containing a C array of T's) and the length of the array Length, there are
various
> tricks for getting an Ada array of the right size (defined on the stack -
important!)
> that uses the block of memory to hold the array data, i.e. no copying
required.
>
> For example,
>
> type Ada_Array is array (Positive range <>) of T;
>
> ...
>
> [have Length and Ptr]
>
> subtype Array2 is Ada_Array (1 .. Length);
>
> X : Array2;
> for X'Address use Ptr; -- ok, Ptr should be of type System'Address, but
hey!
>
> And then you can make use of X.  However being defined on the stack, it
> can be quite awkward to use.  It would be nice to have the same thing but
> with X dynamically allocated.  For example,
>
> type Ada_Array_Pointer is access Ada_Array;
>
> ...
>
> [have Length and Ptr]
>
> X_Ptr : Ada_Array_Pointer;
>
> [do some clever stuff to set up X_Ptr to point to an array where the
> data is given by Ptr, and the bounds are somewhere else, but where? :)]
>
> [Pass X_Ptr around and dereference it etc.]
>
> The problem is the bounds of course.  For example, GNAT usually uses
> fat pointers, consisting of two normal pointers where one points to the
> data, and the other to the bounds.  So the "clever stuff" will need to
> allocate some memory to hold the bounds and set up the fat pointer
> appropriately.
>
> Does anyone know a good way to do this?  The solution only needs to
> work with GNAT.  I appreciate that deallocating the pointer may need
> to be handled specially.
>
> All the best,
>
> Duncan.