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

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.

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

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…

good bye
you won't be missed

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

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 :)

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

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

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