[foreign] Pointer to fixed-size array: is jexctract's mapping to Java correct?

[Maurizio Cimadamore]

That works too - or, and that's where I wanted to get at - you can even 
allocate a single array of double of the right size, and then cast your 
way to it.

What I'm trying to understand here - is there something that the Panama 
API could do better? If so, I'd like to understand exactly what is the 
functionality or the operation that is hard to get at.

Or, is this more an issue with the fact that we'd like to see a better 
type other than Array<Double> for modeling the complex number? If so, 
this is a problem of augmenting the extraction run with user-provided 
metadata, a process that we have internally dubbed 'civilization' of C 
APIs, which is on the radar, but that we're not ready to tackle yet.

Or, is it more a general uneasiness with the fact that some 'dirtiness' 
that was implicit in the C code is now made apparent by the Panama 
bindings? If so, I would call this a feature, rather than a bug :-)

Cheers
Maurizio

On 27/02/2019 21:51, Jorn Vernee wrote:
> Note that you could avoid the allocation and copy by doing:
>
> ```
>     int N = 200; //number of complex pairs
>     try (Scope s = Scope.globalScope().fork()) {
>         Array<Array<Double>> pairs = 
> s.allocateArray(NativeTypes.DOUBLE.array(2), N);
>         for(int i = 0; i < N; i++) {
>             Array<Double> pair = pairs.get(i);
>             pair.set(0, 1D);
>             pair.set(0, 2D);
>         }
>     }
> ```
>
> 'pairs' is just one big slab of memory, and `pairs.get(i)` gets you a 
> 'view' into part of it.
>
> This would work the same with Structs as well.
>
> Jorn
>
> Maurizio Cimadamore schreef op 2019-02-27 22:18:
>> On 27/02/2019 19:23, Lev Serebryakov wrote:
>>> So, semantically speaking, it should be something like (pseudocode, I
>>> know, that we can not have non-type parameters for Java generics)
>>> `Array<FixedArray<Double, 2>>`, or, more realistically, but more
>>> error-prone Array<Array<Double>>, but it will give structure which is
>>> very inconvenient to work with (it is tedious to allocate array for 
>>> each
>>> complex number in this array).
>>
>> So, let me make sure I understand what you are saying:
>>
>> 1) the API takes a pointer-to-array-of-double
>>
>> 2) In reality this means, I want one or more double pairs (where
>> emphasis is on the 'more' side of things)
>>
>> 3) In C, you would just allocate a big slab of memory, big enough to
>> hold the data you need, and fill it accordingly (with all the pairs).
>> Then you pass the pointer to the API and you rely on C loose pointer
>> vs. array semantics
>>
>> 4) The fact that Panama is stricter and it models the signature as
>> Pointer<Array<Double>> is correct, but inconvenient, as now, to call
>> the function, you have to create many Arrays (one for each pair) -
>> that is, it seems less flat that what the C code does - something
>> like:
>>
>>
>> int N = 200; //number of complex pairs
>> try (Scope s = Scope.globalScope().fork()) {
>>    Array<Array<Double>> pairs = 
>> s.allocateArray(NativeTypes.DOUBLE.array(2), N);
>>    for (int i = 0 ; i < N ; i++) {
>>        pairs.set(i, s.allocateArray(NativeTypes.DOUBLE, new double[] {
>> d1, d2 }); // replace d1 and d2 with actual data
>>    }
>>
>>    ...
>>
>>    Pointer<Array<Double>> pairs_ptr = pairs.elementPointer();
>>
>> }
>>
>>
>> Am I right that your discomfort comes from having to allocate all
>> those native arrays? (which will then copied in the destination pair
>> array)
>>
>> Maurizio