luajit-ffi

[so]

On Tuesday, 1 May 2012 at 16:46:32 UTC, Alex Rønne Petersen 
wrote:
> On 01-05-2012 18:15, so wrote:
>> On Tuesday, 1 May 2012 at 15:56:32 UTC, Alex Rønne Petersen 
>> wrote:
>>
>>> What are you talking about? The link you posted clearly shows 
>>> that
>>> LuaJIT has a C parser built in. It has everything to do with 
>>> syntax
>>> (note that FFI is not anything spectacular or innovative; see 
>>> libffi,
>>> Mono, Lisp, ...). And no, D does not "have all the 
>>> structures". If it
>>> did, we wouldn't be redefining them in D bindings.
>>
>> What am "i" talking about? How hard to understand these two 
>> things?
>
> Very hard! You're not making it clear what it is you want!
>
> Do you want something like LuaJIT's FFI so you can just drop a 
> C header in and get a binding or what? You really need to make 
> this clear. I'm not even sure what we're discussing at this 
> point.

Oh! Be prepared...

import capi; // and you are done.

> Yes... I wrote the libffi-d binding. You might want to have a 
> look at your local ffi.h and ffitarget.h to see why the 
> preprocessor is a serious problem in automated binding 
> generation. As another example, look at gc.h from libgc.
>
> No, not really. See above. It may be that simple for the OpenGL 
> headers, but frankly, OpenGL is an example of a reasonably 
> designed library, something that can't be said for 98% of all C 
> libraries.

As you said lets be realistic if we can support things like 
OpenGL/CL with tons of typedefs, enums, defines, function 
declerations (which you said seem to agree that easy). We could 
have 98% of mature C libraries. I don't agree with you on that 
98% of mature libraries designed worse than those. Because since 
they target different languages they tend to have clean 
interfaces.