From: David B. Held (dheld_at_[hidden])
Date: 2002-04-29 23:59:14
"Andrei Alexandrescu" <andrewalex_at_[hidden]> wrote in message
> "David B. Held" <dheld_at_[hidden]> wrote in message
> > [...]
> > 5. Andrei waffled on this one, so I'm not sure whether a change
> > is warranted or not.
> I forgot what that was, and I lost your message.
The issue was whether smart_ptr should support the initialization
of intrusive reference counts.
> As you can see, the value stored is "leaked" in p, and the storage is
> reinitialized. However, the ownership policy is *not* reinitialized, which
> means that, the case of some unusual reference counting scheme, it might
> release something it shouldn't.
Ok, thanks. In the chained policy version, I had to add an init_ownership()
to the Ownership policies (since you can't get at the exact Ownership
policy very easily when it's in a chain, and even if you could, I'm not sure
I could use the solution you offered).
> "Igen" means "Yes" in Hungarian :o).
I suspected as much, but BabelFish doesn't translate Hungarian. ;)
P.S. There is now a chained policy version of boost::loki::smart_ptr at:
The annoying thing is that for the moment, specifying policies is
all-or-nothing. The nice thing is that policies can be chained in
any order, allowing for a large number of inter-policy interactions.
However, StorageTraits must be the first "policy" in the chain. Here
is a sample usage:
boost::default_storage<boost::default_storage_traits<TItem> > > > >
If it is agreed that the policy parameter ought to be a template template
param, then we can probably eliminate specifying T twice. If we can
get a policy mixer together, we can specify only the policies we want,
in any order. At that point, I would say: "Eat your heart out, template
typedefs" ;). Well, template typedefs would still be nice. ;)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk