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

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

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

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

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

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.

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.

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

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!

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.