View mode: basic / threaded / horizontal-split · Log in · Help
May 02, 2012
Re: luajit-ffi
On Tuesday, 1 May 2012 at 16:15:58 UTC, so wrote:
> Have you ever used a C api, say OpenGL?
> What are they using preprocessor for? other than enum and alias?
> It is that damn simple. I am not talking about supporting Boost 
> level preprocessor exploit. I am talking about mature "C" 
> libraries.

Oh _come on_, that's just plain wrong. For example, have you ever 
heard of that library called OpenSSL?

David
May 02, 2012
Re: luajit-ffi
On Wednesday, 2 May 2012 at 11:56:51 UTC, David Nadlinger wrote:
> On Tuesday, 1 May 2012 at 16:15:58 UTC, so wrote:
>> Have you ever used a C api, say OpenGL?
>> What are they using preprocessor for? other than enum and 
>> alias?
>> It is that damn simple. I am not talking about supporting 
>> Boost level preprocessor exploit. I am talking about mature 
>> "C" libraries.
>
> Oh _come on_, that's just plain wrong. For example, have you 
> ever heard of that library called OpenSSL?
>
> David

Why don't you give a link to the source where they use 
preprocessor heavily? And "even" if they do, did i say "all" 
libraries? Yes you managed to come up with a library which 
includes tons of header files in the sea of mature C libraries.
May 02, 2012
Re: luajit-ffi
On Wednesday, 2 May 2012 at 12:36:03 UTC, so wrote:
> Why don't you give a link to the source where they use 
> preprocessor heavily?

Like many other C libraries, OpenSSL implements quite a few 
functions in terms of macros for performance reasons, so that 
they can be inlined (like [1]). Additionally, the OpenSSL guys 
also rely on macros to generate things like their ASN1 interface 
([2], [3]), collections (»safe stacks«), …

> And "even" if they do, did i say "all" libraries? Yes you 
> managed to come up with a library which includes tons of header 
> files in the sea of mature C libraries.

Well, after more or less telling Alex that he has no clue what 
he's talking about, you implied that most of the »mature« 
libraries would make only moderate use of the preprocessor for 
constants. In this generality (»Have you ever used a C api, say 
OpenGL? What are they using preprocessor for? other than enum and 
alias?«), this is simply not true. As Alex pointed out, it's 
often even the other way round: The older and more mature a 
library is, the more preprocessor macros it uses to deal with 
various subtle incompatibilities between all the different 
systems out there…

David


(These links are to
[1] 
https://github.com/D-Programming-Deimos/openssl/blob/master/C/bn.h#L369
[2] 
https://github.com/D-Programming-Deimos/openssl/blob/master/C/asn1.h#L301
[3] 
https://github.com/D-Programming-Deimos/openssl/blob/master/C/asn1t.h#L85
May 02, 2012
Re: luajit-ffi
On Wednesday, 2 May 2012 at 16:23:28 UTC, David Nadlinger wrote:

> Well, after more or less telling Alex that he has no clue what 
> he's talking about,

With no reason, right? Could you go back and read why i did what 
you said i did? I might sometimes sound rude. You can blame my 
temper, nature or lack of (quite obvious) English language 
skills, but these never happen without a reason.

So enum, alias has nothing to do with #define?
Or D requires syntax to support the things i mentioned?
Don't i have a right to expect, someone who answers me already 
understand what i am saying or ask nicely to clear it up?

This is not directing Alex but you since i think we settled the 
issue, yet you jump as a self appointed lawyer. Nothing i hate as 
much as this, pack behavior in humans. It is time for me to leave 
this community too, i can stand many things but this. My start on 
this forum wasn't very bright either. Called troll for a  very 
legitimate question, because a few regulars couldn't comprehend 
the topic i am talking about and/or my cryptic English.

Whatever.

> you implied that most of the »mature« libraries would make 
> only moderate use of the preprocessor for constants. In this 
> generality (»Have you ever used a C api, say OpenGL? What are 
> they using preprocessor for? other than enum and alias?«), 
> this is simply not true. As Alex pointed out, it's often even 
> the other way round: The older and more mature a library is, 
> the more preprocessor macros it uses to deal with various 
> subtle incompatibilities between all the different systems out 
> there…
May 02, 2012
Re: luajit-ffi
good bye
you won't be missed
May 02, 2012
Re: luajit-ffi
On Wednesday, 2 May 2012 at 18:27:18 UTC, agitator wrote:
> good bye
> you won't be missed

I am just trying to find a better tool to ease the work i do, not 
trying to be one as yourself. So as long as D rocks, i ll be 
following. Just not post on forums as it won't do much good when 
you have hard time expressing yourself anyway. I pity you, as i 
believe nothing would be that low on spirit if it wasn't 
disturbed somehow.

Sorry everyone!
I can't restrain the urge to answer such posts.
I feel the presence of some higher powers, yes! they are trying 
to tell me... something, perhaps warning me in a way? I keep 
hearing voices along the lines "NNTP error: 400 loadav 
[innwatch:load] 2084 gt 1500". yet i... must... click "Send"!
May 02, 2012
Re: luajit-ffi
On 5/2/12 1:04 PM, so wrote:
> Sorry everyone!
> I can't restrain the urge to answer such posts.
> I feel the presence of some higher powers, yes! they are trying to tell
> me... something, perhaps warning me in a way? I keep hearing voices
> along the lines "NNTP error: 400 loadav [innwatch:load] 2084 gt 1500".
> yet i... must... click "Send"!

LOL that one made my day!  Glad you're still around :)
May 02, 2012
Re: luajit-ffi
On Wednesday, 2 May 2012 at 17:52:07 UTC, so wrote:
> So enum, alias has nothing to do with #define?
> Or D requires syntax to support the things i mentioned?

#define can be used for manifest constants and aliases, yes, but
also for many other things, as in the examples from popular
libraries that I and others posted. And for an automatic C
importing mechanism to be worth its complexity, it must be able
to handle at least the more common variations.

> Don't i have a right to expect, someone who answers me already 
> understand what i am saying or ask nicely to clear it up?

Frankly, no – just as you answered other posts in this thread
probably without being absolutely sure what the author was trying
to say. Maybe my reply sounded harsher than I intended, I tend to
get annoyed too easily when somebody seems to just ignore
multiple technically sound replies (which people have spent time
writing, after all). I apologize for that.

David
May 02, 2012
Re: luajit-ffi
On Wednesday, 2 May 2012 at 20:04:30 UTC, so wrote:
> I keep hearing voices along the lines "NNTP error: 400 loadav 
> [innwatch:load] 2084 gt 1500". yet i... must... click "Send"!

I might suffer from the same type of schizophrenia ;)

David
May 03, 2012
Re: luajit-ffi
Just pitching in as somebody that has worked on a few C bindings, 
some small some big (current one is XCB, which has the lovely 
xproto.h file coming to over 15000 lines). Doing automatic 
conversion of C headers, properly, is difficult, if not 
impossible. There are all sorts of gotchas and strange things 
that make trying to write bindings difficult to automate.

A lot of APIs rely on the CPP, as part of the API itself. This is 
an issue because you generally need to replicate those parts of 
the API in some D way, without completely mangling the original 
API, generally you want to be able to copy-and-paste C code and 
have it work as D code.

Not all defines can, or should, be converted to enums, even if 
you distinguish macros and constants. Not all typedefs can be 
converted to aliases. Different libraries use different ways of 
typedef'ing their structs and the like. Each library needs a 
specific touch to make the D bindings as true to the original as 
possible, and a tool cannot do that well.

Manually writing bindings is boring, but also quite medatitive. 
It is simple enough that you can just shut off, or you can make 
it a challenge to find the best macro for converting a certain 
construct in this library. But it is generally not that difficult.

The difference between using bindings and FFI is that bindings 
are compile time and you get all the advantages from that, such 
as type checking and the like. FFI is all runtime, so you don't 
get that, unless you do some crazy CTFE magic.

--
James Miller
Next ›   Last »
1 2 3
Top | Discussion index | About this forum | D home