From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-19 12:14:44
--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> > If we fix it so they can place the object on the heap safely we've
> > still not fixed it so they can't then share this object across
> > threads. The only way to fix that would be to synchronize the
> > information which will add a lot of overhead just to protect the
> > from a VERY dubious practice.
> I can't understand why this is controversial. So, we can't prevent
> from touching these things across threads. So what? That's a
> separate issue and nothing you were planning on doing before I made
> argument for counting over state restoration was going to prevent
> either. Even if people behave the way you like and keep the object
> heap, there's no reason they can't touch it across threads. This is
> case where it costs nothing to specify a more robust implementation.
It's not very controversial. As I stated in another thread I just
want some discussion about whether such usage can just lead to other
errors/abuses by the user and whether there's any valid reason for
using the technique in the first place. The specification isn't more
robust if it leads to other errors/abuses with out adding any actual
> > Or are you suggesting we employ one of the techniques to prevent
> > user from even being able to place one of these on the heap?
> I wasn't. If you're going to make it unsafe to put them on the
> should prevent dynamic allocation, but the big problem with those
> is that none of them prevent you from embedding the object in
> which is allocated on the heap (a /very/ likely case). I take this
> another strong argument against making it do state-restoration
Yeah, I know the techniques are fragile, which is why I didn't use
them here or in the scoped_lock classes. I was just curious if that
was what you meant, since I thought I'd explained my reasoning well
enough. Obviously I hadn't, but hopefully this time I have :).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk