notes on binding C++

[Samuel Audet]

Maurizio, Henry, thanks for the clarifications! This is starting to make 
more sense to me. If the goal at the moment is to lay out a foundation 
though, can we consider the parsing functionality in jextract premature 
and that it will not become part of any specs in the near future?

As foundation, data layouts are very interesting, and is something that 
is sorely missing from Java indeed. Currently with JavaCPP, the user has 
the choice between accessing fields easily with JNI, or manually by 
computing offsets from metadata returned by the compiler. I also came up 
with the indexer package (roughly equivalent to the C# functionality 
available under the same name) to access easily and efficiently 
multidimensional data structures from images, matrices, and tensors:
     http://bytedeco.org/news/2014/12/23/third-release/
Although this is useful for a limited number of use cases, those are 
important use cases (<cough>deep learning</cough>). Does the data layout 
functionality of Panama offer that kind of wrapping with strides and 
dimensions? It looks like something is there, but unclear what exactly:
"Multi-dimensional arrays are laid out in row-major order."
https://github.com/J9Java/panama-docs/blob/master/StateOfTheLDL.html

One important feature that is certainty missing from jextract is a way 
to associate a Pointer with native methods. Support for native methods 
is actually a very nice feature of Java, which is missing from C#. We 
can write classes like the following and have all the plumbing generated 
with JNI at build time with a tool like JavaCPP, and it literally just 
works:

public class Something extends Pointer {
     private native allocate();
     public Something() { allocate(); }
}

public class MyCPPClass extends Pointer {
     private native allocate();
     public MyCPPClass() { allocate(); }
     public native Something myFunction(Something something);
}

With jextract (or C# Platform Invoke, cgo, etc), we not only have to 
come up with a wrapper in C, but we end up having to do something like 
this in Java (or C#, Go, etc):

public class CPPPointer {
     Pointer myAddress;
     public CPPPointer(Pointer address) { myAddress = address; }
}

public class Something extends CPPPointer {
     public Something() { address = MyCPPWrapper.i.allocateSomething(); }
     public Something(Pointer address) { super(address); }
}

public class MyCPPClass extends CPPPointer {
     public MyCPPClass() { address = MyCPPWrapper.i.allocateMyCPPClass(); }
     public Something myFunction(Something something) {
         return new Something(wrapper.myFunction(myAddress, 
something.myAddress));
     }
}

interface MyCPPWrapper {
     static MyCPPWrapper i = Library.load(MyCPPWrapper.class);
     Pointer allocateSomething();
     Pointer allocateMyCPPClass();
     Pointer myWrappedFunction(Pointer address, Pointer something);
}

And that does not even account for object deallocation, which JavaCPP 
does transparently with either phantom references or try-with-resources, 
as per the user's wishes. In my opinion, we are regressing in terms of 
usability here. If jextract ever comes up with support for C++ and 
starts outputting code like this, (which by the way is not even safe 
without some guarantees from the code generator) you are basically 
forcing users to use jextract to parse all their header files, probably 
by copy/pasting bits and pieces of them ad hocly à la SWIG until it 
compiles, when they might just want to call only one very specific tiny 
function! If the goal is to build a foundation for C++, that should be a 
priority. I hope I was able to make it clear that figuring support for 
C++ maybe later one day but let's not think about it for now because we 
can do everything with C even if it's not too clean, is not an option. 
We can see what that looks like with CppSharp for an example:
https://github.com/mono/CppSharp/blob/master/docs/GeneratingBindings.md

Samuel

On 02/01/2018 04:04 AM, Henry Jen wrote:
> We had experimented some C++ support, Mikael had being able to make call into C++ for simple case, but as you know, ABI for C++ is not standardized, so this is all experimental and very targeted.
> 
> Ultimate fall back mode, to me, is to writing some C code wrapping up what is needed, then jextract can make call into those C function easily without hassle.
> 
> We are aware, as you suggested, macro/template/inline support is tricky, and we are exploring possibilities. My take is that eventually we are gonna need hints, either by recognizing some common patterns or developer intervention.
> 
> Like Maurizio said, the first phase is to lay out foundation that is solid we can built on, and we like feedbacks to ensure the design won’t prohibit further improvement on support for different languages. We re really focus on fundamentals/primitives allow us to make calls and expressive primitive types, others features should be able to build on top of that without any issue.
> 
> Cheers,
> Henry
>