luajit-ffi

[Alex Rønne Petersen]

On 01-05-2012 18:47, so wrote:
> 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.

D still can't solve the preprocessor problem, so I don't see how it 
would be any easier for D than it is for LuaJIT.

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

No, D really can't solve the preprocessor problem. It's not as simple as 
you think. D does not have any more knowledge about the C compiler 
intended to compile the C library (or the parameters passed to it) than 
LuaJIT does.

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

See my reply to your other post for why this is not sufficient for the 
majority of C libraries.

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

If C++ didn't have C "support", it would probably never have been 
adopted at all. But I never claimed otherwise.

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

-- 
- Alex