Re: Ease of calling C code from D

2014-01-30 Thread Dicebot
On Wednesday, 29 January 2014 at 21:16:26 UTC, Andrej Mitrovic wrote: On 1/28/14, Dicebot pub...@dicebot.lv wrote: There is a dstep package in Arch Linux [community] ;) I was trying out Manjaro recently (yeah I'm a Mint-spoiled n00b) and saw that all D-related packages were packaged by..

Re: Ease of calling C code from D

2014-01-30 Thread Andrej Mitrovic
On 1/30/14, Dicebot pub...@dicebot.lv wrote: Accepting PRs https://github.com/Dicebot/Arch-PKGBUILDs ;) Noted!

Re: Ease of calling C code from D

2014-01-29 Thread w0rp
I think initially getting C libraries to work in D has some hurdles C++ does not. D doesn't support C's pre-processor macros to stop people from using them in D code, compile-time execution of D code and templates are more powerful and easier to verify. D doesn't use null-terminated strings,

Re: Ease of calling C code from D

2014-01-29 Thread Andrej Mitrovic
On 1/28/14, Dicebot pub...@dicebot.lv wrote: There is a dstep package in Arch Linux [community] ;) I was trying out Manjaro recently (yeah I'm a Mint-spoiled n00b) and saw that all D-related packages were packaged by.. Dicebot. :p Thanks!

Ease of calling C code from D

2014-01-28 Thread Atila Neves
One of D's marketed advantages it its compatibility with C. The C standard library is even included! However, after having played around with this quite a bit last week trying to call legacy C code from D, the one thing that put me off and made me think that C++ is better for this for my team

Re: Ease of calling C code from D

2014-01-28 Thread Adam D. Ruppe
On Tuesday, 28 January 2014 at 20:10:00 UTC, Atila Neves wrote: There is htod but it's Windows only. Did you see Jacob's dstep too? https://github.com/jacob-carlborg/dstep I haven't actually used it myself* but it will surely do a better job than the old htod! * I'm often really lazy with

Re: Ease of calling C code from D

2014-01-28 Thread bearophile
Atila Neves: Another problem I had was the silly C code taking char* instead of const char*. Passing in D strings was fun. I don't remember why std.string.toStringz returns a immutable(char)* instead of a char* if you give it a char[]. Bye, bearophile

Re: Ease of calling C code from D

2014-01-28 Thread Craig Dillabaugh
On Tuesday, 28 January 2014 at 20:12:35 UTC, Adam D. Ruppe wrote: On Tuesday, 28 January 2014 at 20:10:00 UTC, Atila Neves wrote: There is htod but it's Windows only. Did you see Jacob's dstep too? https://github.com/jacob-carlborg/dstep I haven't actually used it myself* but it will surely

Re: Ease of calling C code from D

2014-01-28 Thread Dicebot
On Tuesday, 28 January 2014 at 20:55:15 UTC, Craig Dillabaugh wrote: I used dstep to generate a D interface to FFTW (Fastest Fourier-Transform in the West). The header for FFTW includes a massive 100 line (or thereabouts) macro, that basically generates all the function signatures. I ran

Re: Ease of calling C code from D

2014-01-28 Thread Atila Neves
Did you see Jacob's dstep too? I think I read about it here in the forum at some point and somehow forgot about it. I'll definitely give it a go. I also forgot to say that UFCS was pretty cool when dealing with C functions that take a pointer to a struct. Declaring it as ref in D worked

Re: Ease of calling C code from D

2014-01-28 Thread Dicebot
On Tuesday, 28 January 2014 at 22:11:29 UTC, Atila Neves wrote: Did you see Jacob's dstep too? I think I read about it here in the forum at some point and somehow forgot about it. I'll definitely give it a go. There is a dstep package in Arch Linux [community] ;)

Re: Ease of calling C code from D

2014-01-28 Thread Atila Neves
On Tuesday, 28 January 2014 at 22:16:59 UTC, Dicebot wrote: On Tuesday, 28 January 2014 at 22:11:29 UTC, Atila Neves wrote: Did you see Jacob's dstep too? I think I read about it here in the forum at some point and somehow forgot about it. I'll definitely give it a go. There is a dstep

Re: Ease of calling C code from D

2014-01-28 Thread Dicebot
On Tuesday, 28 January 2014 at 22:33:26 UTC, Atila Neves wrote: as far as I can tell no way to specify -I flags so it finds the other headers that get included from the original header. Any normal clang flags can be supplied after input file path, including -I (no pun intended)