On 4/16/12 12:57 PM, Jonathan M Davis wrote:
> So, the problem that we have is basically
>
> void main()
> {
>   Range r;
>   {
>   Container c = //allocated using allocator, however that works
>   r = c[];
>   }
>   //Container may or may not exist in memory, depending on the allocator,
>   //but the range does exist and may or may not be valid.
> }

Yes.

> How is this different from an iterator or range being invalidated after a
> function is called on the container which alters its state?

Well it's just a different matter. In particular containers offer the unstable versions of their primitives when they mess iterators up.

> You could
> theoretically add plumbing to the range to keep track of whether it's valid or
> not, but we're not doing that or planning to do that with std.container are
> we?

I guess we have to, at least plant the decision to do so or not in the allocator or in a policy.


Andrei

On Monday, April 16, 2012 23:07:34 Andrei Alexandrescu wrote:
> On 4/16/12 12:57 PM, Jonathan M Davis wrote:
> > So, the problem that we have is basically
> > 
> > void main()
> > {
> > 
> >   Range r;
> >   {
> >   Container c = //allocated using allocator, however that works
> >   r = c[];
> >   }
> >   //Container may or may not exist in memory, depending on the allocator,
> >   //but the range does exist and may or may not be valid.
> > 
> > }
> 
> Yes.
> 
> > How is this different from an iterator or range being invalidated after a function is called on the container which alters its state?
> 
> Well it's just a different matter. In particular containers offer the unstable versions of their primitives when they mess iterators up.

Yeah, but the example is pretty much the same as code where someone called remove instead of stableRemove. They did something that invalidates the existing ranges for the container. It's just that rather than calling a function to do it, they did it with scope and allocators.

> > You could
> > theoretically add plumbing to the range to keep track of whether it's
> > valid or not, but we're not doing that or planning to do that with
> > std.container are we?
> 
> I guess we have to, at least plant the decision to do so or not in the allocator or in a policy.

I don't really see how else we could handle it. At minimum, if we're going to do it normally, it needs to be via assertions so that they'll go away in release mode - the same goes for checking for ranges which get invalidated by function calls to the container. Otherwise, we get stuck with undesirable overhead.

- Jonathan M Davis