Boost logo

Boost :

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-07-20 12:41:41

From: Peter Dimov <pdimov_at_[hidden]>
> From: "Kevlin Henney" <kevlin_at_[hidden]>
> > > From: "Peter Dimov" <pdimov_at_[hidden]>
> > >Why is a copy-on-write 'any' implementation non-conforming? What (single
> > >threaded) valid user program does not work with a COW implementation?
> >
> > It is not that COW is non-conforming, it is that COW is problematic and
> > often does not deliver the ROI expected of it.
> One common situation where COW does deliver is when any's are placed in a
> std::vector.
> I think I understand why COW is problematic for std::string, but I've
> difficulty envisioning the potential problems with a COWed 'any'. Could you
> elaborate please?
> > >[Note: the current spec does not specify the validity of the pointer
> > >returned by any_cast. Therefore it should be interpreted to be valid
> until
> > >the next 'any' operation. I think that this can be strengthened to 'the
> next
> > >non-const operation' and a COW implementation would still conform.]
> >
> > I think this is a weakness and oversight in the current specification
> > for 'any' (so thanks for pointing this one out!) rather than a loophole
> > to be exploited.
> A loophole? I think that guaranteeing validity until the first non-const
> operation is quite natural; the pointer can't remain valid after operator=
> or clear(). [Hmm, any doesn't have a clear(). :-) No matter, if it had one
> it would invalidate.]
> How would you specify the pointer validity?

End of full expression?

Boost list run by bdawes at, gregod at, cpdaniel at, john at