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
> 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
> > >the next 'any' operation. I think that this can be strengthened to 'the
> > >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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk