ffmbindings manual bindings to C++

[Maurizio Cimadamore]

Hi,
I'm not an expert here -- but I see there's some options to force the 
compiler to emit symbols for inline functions. For instance I see this:

> -fkeep-inline-functions
>            In C, emit "static" functions that are declared "inline" 
> into the
>            object file, even if the function has been inlined into all 
> of its
>            callers.  This switch does not affect functions using the 
> "extern
>            inline" extension in GNU C90.  In C++, emit any and all inline
>            functions into the object file.

I've seen also some pragmas being mentioned -- such as this:

https://clang.llvm.org/docs/AttributeReference.html#used

Of course your mileage might vary -- different compilers might support 
different options, or work in slightly different ways.

And -- the problem is that you have little/no control over whether 
inline symbols are emitted or not. E.g. if you install a C++ lib on your 
system, inline functions will either be there, or they won't. If they 
aren't there there's not much you can do to alter that, except creating 
a shim library which re-exports the inline symbols. But at that point 
you are no longer in "pure" Java.

I think the shim library approach is actually not a bad idea -- 
especially the generation of such a shim library could be automated 
completely -- e.g. some sort of C++ to C transpiler. But, unfortunately, 
while there have been many experiments along those lines, they all seem 
to be abandoned at some point (typically when they get to exceptions 
and/or templates :-) ).

Maurizio


On 05/03/2025 05:30, Lain Lain wrote:
> Do we know if someone is working with C++ committee to include new
> keywords to C++ to help creating bindings? This is not only Java but
> many other languages could benefit from (Rust, ...)
> For example, inline functions are mainly for optimization purposes. If
> compilers knew that inline function may be accessed from other languages
>   they could, in addition to inlining it everywhere, preserve the
> original function so that bindings could access it. Something like
> keyword "extern" which we already have.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250305/00283868/attachment.htm>