luajit-ffi

[so]

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

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