Thread overview | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 29, 2015 extern(C) with function returning user type | ||||
---|---|---|---|---|
| ||||
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 |
July 29, 2015 Re: extern(C) with function returning user type | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kyoji Klyden | 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 |
July 29, 2015 Re: extern(C) with function returning user type | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kyoji Klyden | 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 |
July 29, 2015 Re: extern(C) with function returning user type | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kyoji Klyden | 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 |
July 29, 2015 Re: extern(C) with function returning user type | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | 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 |
July 30, 2015 Re: extern(C) with function returning user type | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kyoji Klyden | 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.
|
July 30, 2015 Re: extern(C) with function returning user type | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike Parker | 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.
|
July 30, 2015 Re: extern(C) with function returning user type | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kyoji Klyden | 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 |
July 31, 2015 Re: extern(C) with function returning user type | ||||
---|---|---|---|---|
| ||||
Posted in reply to bachmeier | 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! |
July 31, 2015 Re: extern(C) with function returning user type | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kyoji Klyden | 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.
|
Copyright © 1999-2021 by the D Language Foundation