luajit-ffi

[Alex Rønne Petersen]

On 01-05-2012 18:08, so wrote:
> On Tuesday, 1 May 2012 at 15:53:37 UTC, Alex Rønne Petersen wrote:
>> On 01-05-2012 17:43, so wrote:
>>> On Tuesday, 1 May 2012 at 15:31:05 UTC, Robert Clipsham wrote:
>>>> On 01/05/2012 16:24, so wrote:
>>>>> http://luajit.org/ext_ffi.html
>>>>> https://github.com/malkia/ufo
>>>>>
>>>>> How awesome is Mike Pall?
>>>>> I didn't dive into details of the code, but if he can do this with a
>>>>> dynamic language, why on earth D still need manual C bindings while
>>>>> having ABI compatibility? So luajit comes with a C compiler?
>>>>
>>>> Note that you can't just drop any C header file in there for that to
>>>> work (as far as I can tell), you still have to bring out individual
>>>> post-processed function declarations.
>>>
>>> https://github.com/malkia/ufo/blob/master/ffi/OpenCL.lua
>>> https://github.com/malkia/ufo/blob/master/ffi/OpenGL.lua
>>> If it can handle these 2 beasts.
>>
>> I see no preprocessor directives.
>
> They are all there as "enum".

That has nothing to do with the C preprocessor... The point here is that 
you can't just copy/paste a C header into LuaJIT's FFI out of the box. 
You have to run the preprocessor on it first, or preprocess it by hand.

>
>>>> Also, someone has written a libffi binding for D, which could probably
>>>> be adapted to work in a similar manor:
>>>>
>>>> https://github.com/lycus/libffi-d
>>>
>>> Neat. Still, having native C libraries means that you can just drop your
>>> C/C++ environment and start D. And i am sure you agree this is by far
>>> the biggest blocker for C/C++ developers.
>>
>> I'm not sure what you're trying to say here. Elaborate/rephrase?
>
> For example in my projects i implement different tasks in different
> libraries.
> All of them have C interfaces. With something like this i could just
> access these libraries as i am accessing in C/C++. Then why do i need to
> go on using C/C++? Transition would be seamless. You can say just write
> the damn bindings and be done with it. But it is neither scalable nor
> maintainable.

Let's be realistic.

In practice, you can almost never just copy/paste a C header into 
LuaJIT's FFI. Even a header guard (#ifndef FOO \ #define FOO \ ... \ 
#endif) will ruin it. The fundamental problem is the C preprocessor. The 
best you can do is take your C header, preprocess it with cpp, and then 
pass it to LuaJIT and hope nothing breaks. Usually, not even an approach 
like that will work because of weird compiler extensions used in headers 
which aren't stripped by cpp.

In an ideal world where no compiler extensions existed, this might have 
had a chance of working, but we all know what the situation with C and 
C++ is.

Yes, creating manual bindings is tedious and annoying to maintain, but 
it is the most foolproof approach.

-- 
- Alex