Don't use arrays as stacks

Nick Sabalausky a at a.a
Wed Sep 28 09:11:29 PDT 2011


"Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message 
news:op.v2ita9hseav7ka at localhost.localdomain...
> On Tue, 27 Sep 2011 00:22:02 -0400, Nick Sabalausky <a at a.a> wrote:
>
> There's never a guarantee that a slice will always point at the current 
> values.  There can't be, because you can never guarantee it will not be 
> reallocated on expansion.
>

Right.

> But what I thought you were talking about is popping values off, and then 
> pushing values on, without exceeding the capacity.  In fact, you would be 
> guaranteed the slice contains the newer values, even if a reallocation 
> occurs, since you have to push values into the slice before exceeding the 
> capacity.
>
> The situation you describe in this reply is, take a slice, push elements 
> on exceeding capacity, then pop elements back, then push elements on. 
> Quite different :)
>

Yes, but the slice "owner" won't necessarily know which of those scenarios 
has occurred. Of course, as it is now, the slice owner won't even know if 
the values it points to have been pooped off and *not* been pushed back on 
again. That said, I agree with you below:

> You could create a "stack slice" which instead of pointing at the memory, 
> points at the stack aggregate itself (which would actually have to be 
> heap-allocated), and have the lower and upper bounds.  Then a "slice" of 
> that type would continue to point at the current data.
>

I should definitely do something like that (or just eliminate the ability to 
take a slice, but I suspect that might be a little more limiting that it 
might initially seem). Or maybe I should just take a look at dcollections ;)




More information about the Digitalmars-d mailing list