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: std.container.array - are these arrays passed by reference?
On Thursday, July 30, 2015 21:05:24 Harry P via Digitalmars-d-learn wrote: > I'm trying to avoid the gc so I'm using std.container.array > arrays instead of the standard ones. I know the standard arrays > return by reference so I imagine that the nogc alternative is > also passed by reference because it'd be a struct with a pointer > and a length, yeah? > > I just want to check in case I'm wrong... Well, aside from the fact that dynamic arrays don't quite have reference semantics, std.container.array is not an array in that sense. It's like a vector in C++ or an ArrayList in Java. It _is_ an actual reference type though (unlike a dynamic array). Its payload is more complicated than a simple pointer and length like a dynamic array, and it uses malloc and free to manage its own memory. But if all you want to do is avoid the GC with dynamic arrays, that works just fine so long as you're not appending to them, reserving space to append, or asking what its capacity is, since all of those involve the GC. You can malloc memory and slice it to get a dynamic array. You just then have to make sure that you manage the lifetime of that memory properly (which generally means not treating the dynamic array as if it owned the memory and being careful that no dynamic arrays which refer to the malloced memory are still around when it's freed). It's certainly easier to use std.container.array than using dynamic arrays with malloc and free, but there's no reason that dynamic arrays would require the GC except for operations related to appending, concatenation, or using new (since new always uses the GC). Simply passing them around and slicing them works just fine. - Jonathan M Davis
std.container.array - are these arrays passed by reference?
I'm trying to avoid the gc so I'm using std.container.array arrays instead of the standard ones. I know the standard arrays return by reference so I imagine that the nogc alternative is also passed by reference because it'd be a struct with a pointer and a length, yeah? I just want to check in case I'm wrong...
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: Yes or No Options
On 07/30/2015 08:14 AM, Chris wrote: I wonder, is your father's company listed among those using D? I think there's a list somewhere on Wiki, if not we should have one :-) I don't think they use D yet but the page is here: http://wiki.dlang.org/Current_D_Use Ali
Re: Yes or No Options
On Thursday, 30 July 2015 at 14:20:41 UTC, Alex wrote: My father owns a small software company, specialized in market data products. www.bccgi.com (in case anyone is interested) So programming was basically around all my life. I do a small job in his company and my next task was to learn D. There are two trainees and the three of us have to learn D. Ofc the two trainees have to learn other languages as well. My dad said the reason why we learn this language is that he personally finds it to be a very intuitive language that produces machine code. If he just wanted us to teach programming he said he'd just told us to learn C#. In addition to that he wants to keep up and always have new languages and features in the company (only 8 people). And since we have experts for almost any language here but not a single one for D, it was time for someone to start! Once I started I found it to be really interesting and challenging plus I like solving problems. Thank you for being so nice! I have seen very few communities where beginners are welcomed so well! Very interesting indeed! Care to write an article about it one day? "Learning D as an absolute beginner" or something like that. I wonder, is your father's company listed among those using D? I think there's a list somewhere on Wiki, if not we should have one :-)
Re: Yes or No Options
My father owns a small software company, specialized in market data products. www.bccgi.com (in case anyone is interested) So programming was basically around all my life. I do a small job in his company and my next task was to learn D. There are two trainees and the three of us have to learn D. Ofc the two trainees have to learn other languages as well. My dad said the reason why we learn this language is that he personally finds it to be a very intuitive language that produces machine code. If he just wanted us to teach programming he said he'd just told us to learn C#. In addition to that he wants to keep up and always have new languages and features in the company (only 8 people). And since we have experts for almost any language here but not a single one for D, it was time for someone to start! Once I started I found it to be really interesting and challenging plus I like solving problems. Thank you for being so nice! I have seen very few communities where beginners are welcomed so well!
Re: Compare types with `static if` in template function.
On Wednesday, 29 July 2015 at 22:40:08 UTC, Ali Çehreli wrote:
You seem to be using type names instead of member names:
static if(is(typeof(c) == dchar) || is(typeof(c) ==
char))
{
slots[xy.y][xy.x].character = c;
}
else if(is(typeof(c) == fg))
{
slots[xy.y][xy.x].fg = c;
Should be
... color = c;
}
else if(is(typeof(c) == bg))
{
slots[xy.y][xy.x].bg = c;
... background = c;
}
else if(is(typeof(c) == md))
{
slots[xy.y][xy.x].md = c;
... mode = c;
}
Ali
Thank you! This was a mistake on my end. Really glad you spotted
it, saved me quite some headaches!
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: Struct that destroys its original handle on copy-by-value
On Wednesday, 29 July 2015 at 19:10:36 UTC, Adam D. Ruppe wrote: On Sunday, 26 July 2015 at 12:16:30 UTC, Joseph Rushton Wakeling wrote: My aim by contrast is to _allow_ that kind of use, but render the original handle empty when it's done. I don't think D offers any way to do that. With the disabled postblit, you can force people into a method you write that returns a new copy and clears the original, but that won't just work with assignment. The ref assign might not be forbidden by the written doc but I'm guessing that is just an oversight - struct assignment in D never clears the original, it is always a simple copy (perhaps plus other code) Hmm... are you implying that `opAssign(ref T other)` should be disallowed? Why? I find this the obvious way to implement move semantics, and it is also what std.algorithm.move does: http://dlang.org/phobos/std_algorithm_mutation.html#.move
Re: Typed Message Passing between D Processes
On Thursday, 30 July 2015 at 05:53:48 UTC, yawniek wrote: On Wednesday, 29 July 2015 at 16:36:41 UTC, Atila Neves wrote: LDC: Cerealed: 970 ms, 482 μs, and 6 hnsecs MsgPack: 896 ms, 591 μs, and 2 hnsecs Not too shabby! Atila cool. what are the advantages of cereald over msgpack? AFAIK, features. The kind of features I need/use to write networking code and reduce the boilerplate to an absolute minimum. can you stream in packets with cereald too? I don't know exactly what you mean. I've only used it to go from network packets structs to bytes and vice-versa. cool thing about msgpack is that there exist libraries for many language. so we use it do actually store logs and then process them with other tools too. I wrote cerealed for networking. You _can_ use it to convert whatever else to binary, but its focus is easy networking. Atila
