"Steven Schveighoffer" <[email protected]> wrote in message news:[email protected]... > On Tue, 27 Sep 2011 00:22:02 -0400, Nick Sabalausky <[email protected]> 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 ;)
