Boost logo

Boost Users :

From: Steve Folly (boost_at_[hidden])
Date: 2004-02-08 04:59:21


On 7/2/04 9:37 pm, in article 20040207213053.M73385_at_[hidden],
"todd" <todd_at_[hidden]> wrote:

> On Sun, 08 Feb 2004 01:28:38 +0000, Steve Folly wrote
>> The problem is to be able to chain then_ and else_ together, I have
>> to return a plain pointer because the if_ statement itself doesn't
>> know about it's shared pointer. So now, the compiler complains that
>> can't implicitly convert a plain if_statement pointer into a shared
>> pointer. And even if it could, I don't have the original shared
>> pointer to hand.
>
> It looks like you can solve this by using intrusive pointers instead of shared
> pointers. The compiler can implicitly convert normal pointers into intrusive
> ones.
>
> Todd

Thanks for your reply, Todd.

Ah - so since my object will always be holding a referece, and I can provide
my intrusive_ptr_release function to release when the ref count is 1? Is
that what you meant?

And all my helper functions will be based on an intrusive pointer, rather
than the shared pointer?

I've noticed that the shared_ptr mechanism is thread safe, but the intrusive
pointer isn't. I don't think that will be a problem because we enforce a
policy of only accessing them from one thread anyway.

I'll have a play.

Cheers,
Steve.


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net