www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Go Your Own Way (Part One: The Stack)

reply Mike Parker <aldacron gmail.com> writes:
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/
Jul 07 2017
next sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
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.
Jul 07 2017
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Jul 07 2017
next sibling parent Guillaume Piolat <first.last gmail.com> writes:
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
Jul 07 2017
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d-announce writes:
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
Jul 07 2017
prev sibling parent "H. S. Teoh via Digitalmars-d-announce" writes:
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
Jul 07 2017
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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_
ne_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
Jul 07 2017
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jul 07 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
Jul 07 2017
next sibling parent Mike Wey <mike-wey example.com> writes:
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
Jul 07 2017
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jul 07 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jul 07 2017
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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.
Jul 07 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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)
Jul 07 2017
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
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!
Jul 07 2017
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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).
Jul 08 2017
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Jul 08 2017
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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
Jul 08 2017
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Jul 07 2017