Re: extern(C) with function returning user type
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. :]
Re: extern(C) with function returning user type
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?
Re: extern(C) with function returning user type
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.
Re: extern(C) with function returning user type
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.
Re: extern(C) with function returning user type
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.
Re: extern(C) with function returning user type
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 :)
Re: extern(C) with function returning user type
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.
Re: extern(C) with function returning user type
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/nsjafpymezlqdknmn...@forum.dlang.org#post-nsjafpymezlqdknmnkhi:40forum.dlang.org That actually seems really interesting, I'll check it out later. Thanks!
Re: extern(C) with function returning user type
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/nsjafpymezlqdknmn...@forum.dlang.org#post-nsjafpymezlqdknmnkhi:40forum.dlang.org -- /Jacob Carlborg
Re: extern(C) with function returning user type
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
Re: extern(C) with function returning user type
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
Re: extern(C) with function returning user type
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
Re: extern(C) with function returning user type
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/yheamworbhcaprrko...@forum.dlang.org
Re: extern(C) with function returning user type
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.
