• Kyoji Klyden (9/9) Jul 29 2015 How would I use a C function that's returning a struct? auto
• yawniek (5/14) Jul 29 2015 checkout dstep https://github.com/jacob-carlborg/dstep
• anonymous (10/19) Jul 29 2015 D can't import C header files. And I don't think such a feature
• =?UTF-8?B?QWxpIMOHZWhyZWxp?= (8/12) Jul 29 2015 Header files require a C preprocessor but D does not have one and it
• Kyoji Klyden (3/3) Jul 29 2015 Thanks for the replies,
• Mike Parker (9/12) Jul 29 2015 Really? I see it as one of D's strengths. It's much easier to
• bachmeier (7/22) Jul 30 2015 I agree. The last thing we want is C header files being valid D
• Kyoji Klyden (20/52) Jul 30 2015 Being that my skills in C and D are pretty much tied, I regularly
• bachmeier (5/11) Jul 31 2015 That's how you end up with C++. The solution there is to use only
• Kyoji Klyden (5/16) Jul 31 2015 It's a fair argument. Regardless though, I feel like D has lost
• Laeeth Isharc (12/31) Jul 31 2015 You have to make the right decision for you.
• Kyoji Klyden (8/40) Jul 31 2015 I definitely agree with you there. I'm sure dstep could work
• Laeeth Isharc (23/67) Jul 31 2015 Walter observes that if you are a Java programmer and start
• Kyoji Klyden (37/59) Aug 01 2015 Oddly enough, before D I was a python guy. I took up C about year
• Jacob Carlborg (6/9) Jul 30 2015 You might want to check out Calypso [1] as well.

"Kyoji Klyden" <kyojiklyden yahoo.com> writes:

How would I use a C function that's returning a struct? auto 
doesn't work here, and from what I can tell D can't import C 
headers. (If it really can't then, that would be a very welcome 
feature)

I do have the required libs but I can't create my D obj file so I 
can't really get there.

I know that there htod but, is there anyway I can avoid using 
that?

I'm using GDC, and GCC on Win7

"yawniek" <dlang srtnwz.com> writes:

On Wednesday, 29 July 2015 at 17:59:26 UTC, Kyoji Klyden wrote:
 How would I use a C function that's returning a struct? auto 
 doesn't work here, and from what I can tell D can't import C 
 headers. (If it really can't then, that would be a very welcome 
 feature)

 I do have the required libs but I can't create my D obj file so 
 I can't really get there.

 I know that there htod but, is there anyway I can avoid using 
 that?

 I'm using GDC, and GCC on Win7

checkout dstep https://github.com/jacob-carlborg/dstep

i think you can just define a struct with the same shape.
see also mike's answer on 
http://forum.dlang.org/post/yheamworbhcaprrkoflp forum.dlang.org

"anonymous" <anonymous example.com> writes:

On Wednesday, 29 July 2015 at 17:59:26 UTC, Kyoji Klyden wrote:
 How would I use a C function that's returning a struct? auto 
 doesn't work here, and from what I can tell D can't import C 
 headers. (If it really can't then, that would be a very welcome 
 feature)

 I do have the required libs but I can't create my D obj file so 
 I can't really get there.

 I know that there htod but, is there anyway I can avoid using 
 that?

 I'm using GDC, and GCC on Win7

D can't import C header files. And I don't think such a feature 
is planned right now.

You have to translate the C declarations to D, both struct and 
function. You can do that either manually or using some tool.

If you go the manual route, there's a page on that:
http://dlang.org/ctod.html

For tools, if you're not happy with htod, maybe DStep works 
better:
https://github.com/jacob-carlborg/dstep

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 07/29/2015 10:59 AM, Kyoji Klyden wrote:

 How would I use a C function that's returning a struct?

The binding file must have a matching D struct.

 auto doesn't
 work here, and from what I can tell D can't import C headers. (If it
 really can't then, that would be a very welcome feature)

Header files require a C preprocessor but D does not have one and it 
does not want one. :)

Check Deimos for examples and whether there are bindings already 
available for your lib:

   https://github.com/D-Programming-Deimos/

Ali

"Kyoji Klyden" <kyojiklyden yahoo.com> writes:

Thanks for the replies,

This issue really highlights one of D's weak points I think.

I've atleast got a round about solution almost working. :P

"Mike Parker" <aldacron gmail.com> writes:

On Wednesday, 29 July 2015 at 18:42:45 UTC, Kyoji Klyden wrote:
 Thanks for the replies,

 This issue really highlights one of D's weak points I think.

 I've atleast got a round about solution almost working. :P

Really? I see it as one of D's strengths. It's much easier to 
connect D with C than it is to connect other languages with C. 
Essentially, you're just rewriting the C header in D and that's 
it. It's as simple as it can get without the compiler being able 
to directly parse C headers. In that case, the compiler would 
either be needlessly complex or have a dependency on something 
like libclang. This is much more appropriate for a tool, not the 
compiler. Besides, it's quite easy to do it by hand.

"bachmeier" <no spam.net> writes:

On Thursday, 30 July 2015 at 01:14:06 UTC, Mike Parker wrote:
 On Wednesday, 29 July 2015 at 18:42:45 UTC, Kyoji Klyden wrote:
 Thanks for the replies,

 This issue really highlights one of D's weak points I think.

 I've atleast got a round about solution almost working. :P

 Really? I see it as one of D's strengths. It's much easier to 
 connect D with C than it is to connect other languages with C. 
 Essentially, you're just rewriting the C header in D and that's 
 it. It's as simple as it can get without the compiler being 
 able to directly parse C headers. In that case, the compiler 
 would either be needlessly complex or have a dependency on 
 something like libclang. This is much more appropriate for a 
 tool, not the compiler. Besides, it's quite easy to do it by 
 hand.

I agree. The last thing we want is C header files being valid D 
code. It would make C programmers happy, but understanding those 
ugly files would then become a requirement for anyone coming from 
a different background, and that would not be good. Trivial 
interoperability (even if it's inconvenient) that leaves the two 
languages separate is far better.

"Kyoji Klyden" <kyojiklyden yahoo.com> writes:

On Thursday, 30 July 2015 at 11:32:10 UTC, bachmeier wrote:
 On Thursday, 30 July 2015 at 01:14:06 UTC, Mike Parker wrote:
 On Wednesday, 29 July 2015 at 18:42:45 UTC, Kyoji Klyden wrote:
 Thanks for the replies,

 This issue really highlights one of D's weak points I think.

 I've atleast got a round about solution almost working. :P

 Really? I see it as one of D's strengths. It's much easier to 
 connect D with C than it is to connect other languages with C. 
 Essentially, you're just rewriting the C header in D and 
 that's it. It's as simple as it can get without the compiler 
 being able to directly parse C headers. In that case, the 
 compiler would either be needlessly complex or have a 
 dependency on something like libclang. This is much more 
 appropriate for a tool, not the compiler. Besides, it's quite 
 easy to do it by hand.

 I agree. The last thing we want is C header files being valid D 
 code. It would make C programmers happy, but understanding 
 those ugly files would then become a requirement for anyone 
 coming from a different background, and that would not be good. 
 Trivial interoperability (even if it's inconvenient) that 
 leaves the two languages separate is far better.

Being that my skills in C and D are pretty much tied, I regularly 
find myself writing a D program, only to find that I can't 
actually link with whatever C based library I'm using at the 
moment, so it actually ends up being faster and far more 
efficient to just rewrite all my D source in C (and a tiny bit of 
C++ if I really have to).

 From D, using C functions is easy, but I always run into trouble 
when it comes to any of the user types. So I guess I could bind 
it, but again that can take too much time when you got 20 massive 
headers all referencing each other.

So idk, it feels silly and counterproductive to have D not able 
to natively use C libraries. Are we just gonna have to write D 
bindings to every notable library out there? Also I don't see how 
it'd be problematic, if you don't want a C preprocessor kicking 
in, then just don't import any C source, and then the compiler 
will just skip that step.  :P


On Thursday, 30 July 2015 at 18:26:15 UTC, Jacob Carlborg wrote:
 On 2015-07-29 20:42, Kyoji Klyden wrote:
 Thanks for the replies,

 This issue really highlights one of D's weak points I think.

 I've atleast got a round about solution almost working. :P

 You might want to check out Calypso [1] as well.

 [1] 
 http://forum.dlang.org/thread/nsjafpymezlqdknmnkhi forum.dlang.org#post-nsjafpymezlqdknmnkhi:40forum.dlang.org

That actually seems really interesting, I'll check it out later. 
Thanks!

"bachmeier" <no spam.net> writes:

On Friday, 31 July 2015 at 03:30:20 UTC, Kyoji Klyden wrote:
 So idk, it feels silly and counterproductive to have D not able 
 to natively use C libraries. Are we just gonna have to write D 
 bindings to every notable library out there? Also I don't see 
 how it'd be problematic, if you don't want a C preprocessor 
 kicking in, then just don't import any C source, and then the 
 compiler will just skip that step.  :P

That's how you end up with C++. The solution there is to use only 
a subset of the language, but since everyone has her own subset, 
you can either learn the whole language or not interact with 
anyone else's code. A tool-based solution is much better.

"Kyoji Klyden" <kyojiklyden yahoo.com> writes:

On Friday, 31 July 2015 at 16:09:23 UTC, bachmeier wrote:
 On Friday, 31 July 2015 at 03:30:20 UTC, Kyoji Klyden wrote:
 So idk, it feels silly and counterproductive to have D not 
 able to natively use C libraries. Are we just gonna have to 
 write D bindings to every notable library out there? Also I 
 don't see how it'd be problematic, if you don't want a C 
 preprocessor kicking in, then just don't import any C source, 
 and then the compiler will just skip that step.  :P

 That's how you end up with C++. The solution there is to use 
 only a subset of the language, but since everyone has her own 
 subset, you can either learn the whole language or not interact 
 with anyone else's code. A tool-based solution is much better.

It's a fair argument. Regardless though, I feel like D has lost 
it practicality for me for the time being. I might come back to 
it in half a year and see if anything changes, but unfortunately 
I don't see myself using D for any of my projects I got lined up.

"Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:

On Friday, 31 July 2015 at 17:14:29 UTC, Kyoji Klyden wrote:
 On Friday, 31 July 2015 at 16:09:23 UTC, bachmeier wrote:
 On Friday, 31 July 2015 at 03:30:20 UTC, Kyoji Klyden wrote:
 So idk, it feels silly and counterproductive to have D not 
 able to natively use C libraries. Are we just gonna have to 
 write D bindings to every notable library out there? Also I 
 don't see how it'd be problematic, if you don't want a C 
 preprocessor kicking in, then just don't import any C source, 
 and then the compiler will just skip that step.  :P

 That's how you end up with C++. The solution there is to use 
 only a subset of the language, but since everyone has her own 
 subset, you can either learn the whole language or not 
 interact with anyone else's code. A tool-based solution is 
 much better.

 It's a fair argument. Regardless though, I feel like D has lost 
 it practicality for me for the time being. I might come back to 
 it in half a year and see if anything changes, but 
 unfortunately I don't see myself using D for any of my projects 
 I got lined up.

You have to make the right decision for you.

But from what you say, I am not sure if you are making it on the 
basis of proper information about the tradeoffs involved.  It 
shouldn't be a difficult thing to port the headers for most C 
libraries.  Use dstep to do the work, and a bit of tidying up 
after (which gets easier each time).  Less time involved than 
that involved in trying to fix just one nasty memory leak or 
pointer problem in C code.

Sometimes though, cashflow dominates return on investment.  If 
one cannot spare the time then, ROI on learning something new is 
irrelevant.  One can't do much about that in the short term.

"Kyoji Klyden" <kyojiklyden yahoo.com> writes:

On Friday, 31 July 2015 at 19:13:18 UTC, Laeeth Isharc wrote:
 On Friday, 31 July 2015 at 17:14:29 UTC, Kyoji Klyden wrote:
 On Friday, 31 July 2015 at 16:09:23 UTC, bachmeier wrote:
 On Friday, 31 July 2015 at 03:30:20 UTC, Kyoji Klyden wrote:
 So idk, it feels silly and counterproductive to have D not 
 able to natively use C libraries. Are we just gonna have to 
 write D bindings to every notable library out there? Also I 
 don't see how it'd be problematic, if you don't want a C 
 preprocessor kicking in, then just don't import any C 
 source, and then the compiler will just skip that step.  :P

 That's how you end up with C++. The solution there is to use 
 only a subset of the language, but since everyone has her own 
 subset, you can either learn the whole language or not 
 interact with anyone else's code. A tool-based solution is 
 much better.

 It's a fair argument. Regardless though, I feel like D has 
 lost it practicality for me for the time being. I might come 
 back to it in half a year and see if anything changes, but 
 unfortunately I don't see myself using D for any of my 
 projects I got lined up.

 You have to make the right decision for you.

 But from what you say, I am not sure if you are making it on 
 the basis of proper information about the tradeoffs involved.  
 It shouldn't be a difficult thing to port the headers for most 
 C libraries.  Use dstep to do the work, and a bit of tidying up 
 after (which gets easier each time).  Less time involved than 
 that involved in trying to fix just one nasty memory leak or 
 pointer problem in C code.

 Sometimes though, cashflow dominates return on investment.  If 
 one cannot spare the time then, ROI on learning something new 
 is irrelevant.  One can't do much about that in the short term.

I definitely agree with you there. I'm sure dstep could work 
quite well, but at the same time, for what I'm doing, there's 
nothing in D I couldn't do in C, and C's the one with the 
libraries + the endless supply of documentation. There really 
isn't any reward for that extra percent of time/effort spent when 
using D right now.
I still think D is rad, and will probably use it again sometime :)

"Laeeth Isharc" <laeethnospam nospam.laeeth.com> writes:

On Friday, 31 July 2015 at 21:35:30 UTC, Kyoji Klyden wrote:
 On Friday, 31 July 2015 at 19:13:18 UTC, Laeeth Isharc wrote:
 On Friday, 31 July 2015 at 17:14:29 UTC, Kyoji Klyden wrote:
 On Friday, 31 July 2015 at 16:09:23 UTC, bachmeier wrote:
 On Friday, 31 July 2015 at 03:30:20 UTC, Kyoji Klyden wrote:
 So idk, it feels silly and counterproductive to have D not 
 able to natively use C libraries. Are we just gonna have to 
 write D bindings to every notable library out there? Also I 
 don't see how it'd be problematic, if you don't want a C 
 preprocessor kicking in, then just don't import any C 
 source, and then the compiler will just skip that step.  :P

 That's how you end up with C++. The solution there is to use 
 only a subset of the language, but since everyone has her 
 own subset, you can either learn the whole language or not 
 interact with anyone else's code. A tool-based solution is 
 much better.

 It's a fair argument. Regardless though, I feel like D has 
 lost it practicality for me for the time being. I might come 
 back to it in half a year and see if anything changes, but 
 unfortunately I don't see myself using D for any of my 
 projects I got lined up.

 You have to make the right decision for you.

 But from what you say, I am not sure if you are making it on 
 the basis of proper information about the tradeoffs involved.  
 It shouldn't be a difficult thing to port the headers for most 
 C libraries.  Use dstep to do the work, and a bit of tidying 
 up after (which gets easier each time).  Less time involved 
 than that involved in trying to fix just one nasty memory leak 
 or pointer problem in C code.

 Sometimes though, cashflow dominates return on investment.  If 
 one cannot spare the time then, ROI on learning something new 
 is irrelevant.  One can't do much about that in the short term.

 I definitely agree with you there. I'm sure dstep could work 
 quite well, but at the same time, for what I'm doing, there's 
 nothing in D I couldn't do in C, and C's the one with the 
 libraries + the endless supply of documentation. There really 
 isn't any reward for that extra percent of time/effort spent 
 when using D right now.
 I still think D is rad, and will probably use it again sometime 
 :)

Walter observes that if you are a Java programmer and start 
writing D, you will write D like you write Java.  And so I 
suppose one will see what one doesn't have in Java, but not so 
much the benefits of D.  That's true of other languages too.  
When one learns something new, one is often initially worse off 
as a result, because it destabilises ones habits before one sees 
how to apply ones new knowledge.  So those benefits only come 
with persistence and the passage of time.

Language familiarity can also be deceptive - "D adds nothing 
really new" say the Reddit guys.  But as a C guy who never got 
into C++, it makes a huge difference.  Just not obviously so in 
the beginning.  One thing that's great is to be able to come back 
to my own code after a break when it was written in a hurry and 
without too many comments and tie be able to understand it 
immediately.  That wasn't my experience with C, but I suppose it 
depends how much discipline you have.  (Also, once it compiles, 
the bugs are usually obvious enough and simple to fix - stronger 
typing has benefits).

The main advantage I have found is that one can deploy limited 
energy to achieve more, because one doesn't get as bogged down, 
and because the work is more pleasant and satisfying.

Which libraries do you miss, out of interest?

"Kyoji Klyden" <kyojiklyden yahoo.com> writes:

On Saturday, 1 August 2015 at 04:11:02 UTC, Laeeth Isharc wrote:
 Walter observes that if you are a Java programmer and start 
 writing D, you will write D like you write Java.  And so I 
 suppose one will see what one doesn't have in Java, but not so 
 much the benefits of D.  That's true of other languages too.  
 When one learns something new, one is often initially worse off 
 as a result, because it destabilises ones habits before one 
 sees how to apply ones new knowledge.  So those benefits only 
 come with persistence and the passage of time.

 Language familiarity can also be deceptive - "D adds nothing 
 really new" say the Reddit guys.  But as a C guy who never got 
 into C++, it makes a huge difference.  Just not obviously so in 
 the beginning.  One thing that's great is to be able to come 
 back to my own code after a break when it was written in a 
 hurry and without too many comments and tie be able to 
 understand it immediately.  That wasn't my experience with C, 
 but I suppose it depends how much discipline you have.  (Also, 
 once it compiles, the bugs are usually obvious enough and 
 simple to fix - stronger typing has benefits).

 The main advantage I have found is that one can deploy limited 
 energy to achieve more, because one doesn't get as bogged down, 
 and because the work is more pleasant and satisfying.

 Which libraries do you miss, out of interest?

Oddly enough, before D I was a python guy. I took up C about year 
after starting D. So I definitely see the python influence in my 
coding style, in both C and D. I keep everything very minimal and 
tidy, so my code is always really readable; but at the same time 
it has made me slightly hesitant to take up some of D's more 
unique features, so there's definitely still alot of areas with D 
I know I could improve in. However, there's points with D that I 
know the work around to certain problems is to use some other 
language, because D's design for better or worse won't let me 
solve the problem in a effective or sane method.
I agree with you completely about how easy D makes certain 
things. It's just that the bigger or more complex a project 
becomes, I find that it doesn't matter how the language works, 
things are just gonna get messy.

For libraries, most of them have some type of D binding available 
(of varying quality). Csound doesn't have a D binding, I don't 
think there's a Bullet3 binding, the alembic library(which is on 
my todo to use) doesn't have D binding, and the WinAPI is very 
weird to use from D. Also software APIs such as Softimage or 
Houdini's API don't have one. There's a bunch of others too. I 
think alot of this comes from game/interactive application 
programmers being in the minority in the D community.
I generally don't like the whole binding scenario anyways, 
because there's always a bit of delay between updates in the 
library and the binding, and I'm unfortunately very reliant on 
other people's libraries at the moment :\

Also one of my hobbies that I've gotten into in the last few 
months is writing code for weird processors types (i.e. the MOS 
6502, or the SX processor). There's always atleast a C compiler 
available (either official or community made). So even wishing 
for a D compiler for all those uncommon architectures is foolish.

Being that I have a decent idea of what I'm doing these days, 
it's not to hard to jump languages; but since knowing how to use 
a language and how to actually excel at a language is two very 
different things, I've chosen to get as good as possible at C, 
since there will be a much much larger payoff right now.  :]

Jacob Carlborg <doob me.com> writes:

On 2015-07-29 20:42, Kyoji Klyden wrote:
 Thanks for the replies,

 This issue really highlights one of D's weak points I think.

 I've atleast got a round about solution almost working. :P

You might want to check out Calypso [1] as well.

[1] 
http://forum.dlang.org/thread/nsjafpymezlqdknmnkhi forum.dlang.org#post-nsjafpymezlqdknmnkhi:40forum.dlang.org

-- 
/Jacob Carlborg