Re: Go Your Own Way (Part One: The Stack)
On 7/7/17 9:51 PM, Mike Parker wrote: On Saturday, 8 July 2017 at 01:28:59 UTC, Walter Bright wrote: On 7/7/2017 4:35 PM, Nicholas Wilson wrote: It's an intrinsic in LDC. We can certainly drop the per platform and move to a per compiler definition instead. It's already there under: version (DigitalMars) I read this as CRuntime_DigitalMars, which prompted a search that led me to a page at MSDN on _alloca, which gave me a compiler error when I prototyped it, which led to my prototyping alloca for CRuntime_Microsoft and finding success, which has now confirmed my worry that publishing without a review was a bad idea. I've updated the post. Thanks! Ha! as someone who doesn't regularly develop on Windows, I didn't even test. I should have known better, as I've used alloca in druntime, and that wouldn't work if it didn't build on Win64. -Steve
Re: Go Your Own Way (Part One: The Stack)
On 7/7/2017 6:51 PM, Mike Parker wrote: I read this as CRuntime_DigitalMars, which prompted a search that led me to a page at MSDN on _alloca, which gave me a compiler error when I prototyped it, which led to my prototyping alloca for CRuntime_Microsoft and finding success, which has now confirmed my worry that publishing without a review was a bad idea. I've updated the post. Thanks! alloca() being a compiler intrinsic means the version should be about the host compiler, not the particular runtime (though they usually go together, but not always).
Re: Go Your Own Way (Part One: The Stack)
On 7/7/2017 6:28 PM, Walter Bright wrote: On 7/7/2017 4:35 PM, Nicholas Wilson wrote: It's an intrinsic in LDC. We can certainly drop the per platform and move to a per compiler definition instead. It's already there under: version (DigitalMars) Just to beat that dead horse into the dust: https://github.com/dlang/druntime/blob/master/src/core/stdc/stdlib.d#L216
Re: Go Your Own Way (Part One: The Stack)
On Saturday, 8 July 2017 at 01:28:59 UTC, Walter Bright wrote: On 7/7/2017 4:35 PM, Nicholas Wilson wrote: It's an intrinsic in LDC. We can certainly drop the per platform and move to a per compiler definition instead. It's already there under: version (DigitalMars) I read this as CRuntime_DigitalMars, which prompted a search that led me to a page at MSDN on _alloca, which gave me a compiler error when I prototyped it, which led to my prototyping alloca for CRuntime_Microsoft and finding success, which has now confirmed my worry that publishing without a review was a bad idea. I've updated the post. Thanks!
Re: Go Your Own Way (Part One: The Stack)
On 7/7/2017 4:35 PM, Nicholas Wilson wrote: It's an intrinsic in LDC. We can certainly drop the per platform and move to a per compiler definition instead. It's already there under: version (DigitalMars)
Re: Go Your Own Way (Part One: The Stack)
On Fri, Jul 07, 2017 at 07:12:28PM -0600, Jonathan M Davis via Digitalmars-d-announce wrote: > On Friday, July 7, 2017 1:48:47 PM MDT Adam D. Ruppe via Digitalmars-d- > announce wrote: [...] > > The implicit slice is one of what I see as D's design flaws and > > brings up a number of problems. dip1000 and similar things might be > > able to fix the problems without changing the feature, but I won't > > be surprised if after a couple more years, we see that implicit > > slice get deprecated. I'm also against implicit slicing of static arrays. It's just too dangerous, and also interacts poorly with template functions. > The trick is convincing Walter. The last time I brought it up with > him, he thought that improvements to @safe would fix the problem - and > they will help - but it interacts badly with templated code, and I > think that from a code clarity standpoint, the slicing needs to be > explicit. So, I'm of the opinion that implicit slicing should simply > be deprecated regardless of the state of @safe, but I don't know how > possible it is to convince Walter of that. Fixing the @safe issues is > at least a start though. [...] It's true that fixing @safe issues will at least reduce the problem surface of implicit slicing. But it's like bandaid over a festering wound; the problem is still there, it just lurks in more obscure corners now. T -- If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher
Re: Go Your Own Way (Part One: The Stack)
On Friday, July 7, 2017 1:48:47 PM MDT Adam D. Ruppe via Digitalmars-d- announce wrote: > I would add a note to the "static arrays are interchangeable with > dynamic arrays" saying that you can... and probably should > explicitly slice them with `[]`. > > The implicit slice is one of what I see as D's design flaws and > brings up a number of problems. dip1000 and similar things might > be able to fix the problems without changing the feature, but I > won't be surprised if after a couple more years, we see that > implicit slice get deprecated. The trick is convincing Walter. The last time I brought it up with him, he thought that improvements to @safe would fix the problem - and they will help - but it interacts badly with templated code, and I think that from a code clarity standpoint, the slicing needs to be explicit. So, I'm of the opinion that implicit slicing should simply be deprecated regardless of the state of @safe, but I don't know how possible it is to convince Walter of that. Fixing the @safe issues is at least a start though. - Jonathan M Davis
Re: Go Your Own Way (Part One: The Stack)
On Friday, 7 July 2017 at 22:42:08 UTC, Walter Bright wrote: On 7/7/2017 1:33 PM, Steven Schveighoffer wrote: Since it's an intrinsic (as confirmed by you), maybe we can just drop the version conditions? The compiler will always generate it, regardless of C lib, right? I'll do the PR if you agree (just want to make sure I understand your statements about it). DMD will. I don't know about LDC or GDC. It's an intrinsic in LDC. We can certainly drop the per platform and move to a per compiler definition instead.
Re: Go Your Own Way (Part One: The Stack)
On 7/7/2017 1:33 PM, Steven Schveighoffer wrote: Since it's an intrinsic (as confirmed by you), maybe we can just drop the version conditions? The compiler will always generate it, regardless of C lib, right? I'll do the PR if you agree (just want to make sure I understand your statements about it). DMD will. I don't know about LDC or GDC.
Re: Go Your Own Way (Part One: The Stack)
On 7/7/17 4:10 PM, Walter Bright wrote: On 7/7/2017 12:38 PM, Steven Schveighoffer wrote: Which would mean that the lack of alloca prototype on Windows is a straight up bug (the fact that you can just add the declaration and it works is pretty good proof). It's in core.stdc.stdlib Since it's an intrinsic (as confirmed by you), maybe we can just drop the version conditions? The compiler will always generate it, regardless of C lib, right? I'll do the PR if you agree (just want to make sure I understand your statements about it). -Steve
Re: Go Your Own Way (Part One: The Stack)
On 07-07-17 22:10, Walter Bright wrote: On 7/7/2017 12:38 PM, Steven Schveighoffer wrote: Which would mean that the lack of alloca prototype on Windows is a straight up bug (the fact that you can just add the declaration and it works is pretty good proof). It's in core.stdc.stdlib Only for version DigitalMars and GNU. -- Mike Wey
Re: Go Your Own Way (Part One: The Stack)
On 7/7/2017 12:38 PM, Steven Schveighoffer wrote: Which would mean that the lack of alloca prototype on Windows is a straight up bug (the fact that you can just add the declaration and it works is pretty good proof). It's in core.stdc.stdlib
Re: Go Your Own Way (Part One: The Stack)
On 7/7/2017 12:36 PM, Steven Schveighoffer wrote: I thought alloca was an intrinsic? Which means that the compiler generates inline code to add to the stack. I would think it has to do this, since actually calling a function would generate a new stack frame. Yes and yes.
Re: Go Your Own Way (Part One: The Stack)
On 7/7/17 3:36 PM, Steven Schveighoffer wrote: I thought alloca was an intrinsic? Which means that the compiler generates inline code to add to the stack. Which would mean that the lack of alloca prototype on Windows is a straight up bug (the fact that you can just add the declaration and it works is pretty good proof). -Steve
Re: Go Your Own Way (Part One: The Stack)
On 7/7/17 8:59 AM, Mike Parker wrote: This is my latest post in the GC series. I had promised the next one would look at non-GC allocation strategies, but as it got longer and longer I decided to break it up into two parts. This part covers stack allocations. The next one will deal with non-GC heap allocations. If my luck holds out, we're about to see a flurry of guest posts and collaborations over the next few weeks. If that pans out, I expect to publish the part two in mid-late August. The blog: https://dlang.org/blog/2017/07/07/go-your-own-way-part-one-the-stack/ Reddit: https://www.reddit.com/r/programming/comments/6ltfwx/go_your_own_way_part_one_of_two_on_nongc/ I thought alloca was an intrinsic? Which means that the compiler generates inline code to add to the stack. I would think it has to do this, since actually calling a function would generate a new stack frame. -Steve
Re: Go Your Own Way (Part One: The Stack)
On Friday, 7 July 2017 at 13:48:47 UTC, Adam D. Ruppe wrote: I would add a note to the "static arrays are interchangeable with dynamic arrays" saying that you can... and probably should explicitly slice them with `[]`. The implicit slice is one of what I see as D's design flaws and brings up a number of problems. dip1000 and similar things might be able to fix the problems without changing the feature, but I won't be surprised if after a couple more years, we see that implicit slice get deprecated. +1 it only creates confusion
Re: Go Your Own Way (Part One: The Stack)
I would add a note to the "static arrays are interchangeable with dynamic arrays" saying that you can... and probably should explicitly slice them with `[]`. The implicit slice is one of what I see as D's design flaws and brings up a number of problems. dip1000 and similar things might be able to fix the problems without changing the feature, but I won't be surprised if after a couple more years, we see that implicit slice get deprecated.
Re: Go Your Own Way (Part One: The Stack)
On Friday, 7 July 2017 at 12:59:44 UTC, Mike Parker wrote: This is my latest post in the GC series. I had promised the next one would look at non-GC allocation strategies, but as it got longer and longer I decided to break it up into two parts. This part covers stack allocations. The next one will deal with non-GC heap allocations. If my luck holds out, we're about to see a flurry of guest posts and collaborations over the next few weeks. If that pans out, I expect to publish the part two in mid-late August. The blog: https://dlang.org/blog/2017/07/07/go-your-own-way-part-one-the-stack/ Reddit: https://www.reddit.com/r/programming/comments/6ltfwx/go_your_own_way_part_one_of_two_on_nongc/ Nicely written as usual, keep those posts coming :P BTW, I noticed that the "Learn" button doesn't point to the DLang Tour, like it does on dlang.org, so I opened a PR to fix this: https://github.com/dlang/D-Blog-Theme/pull/21.
