luajit-ffi

[so]

On Tuesday, 1 May 2012 at 16:31:09 UTC, Alex Rønne Petersen 
wrote:

> 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.

Well i didn't say you can. But D have great advantages over Lua 
to be able to do that and much more.

> 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.

Again, you can't do that in lua but you should be able to do it 
in D. If you check some lua bindings, libraries tries to simplify 
the process, all the duplicate stuff they do on tons of different 
projects. All for nothing, and i am sure this is true for many 
other languages. And then you see luajit-ffi, gives both 
performance boost and soooo much clean code.

This discussion came up before and preprocessor was the only 
serious blocker. But if you support it to the level what mature C 
libraries use, which means simple alias and enum you have them 
all.

> 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.

I am not sure if C++ had quarter of its user base if it didn't 
work with C seamlessly.

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

In another language there may not be other exit but D, i am not 
sure.