Re: [boost] intrusive_ptr design question

Subject: Re: [boost] intrusive_ptr design question
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-07-06 11:32:56

Zachary Turner wrote:
>
> Ok, so let me rephrase then: Is there a case to be made for a more
> flexible shared_ptr (either through modification or through a new
> class addition) that allows one to provide custom reference counting
> semantics much the same way that shared_ptr allows one to provide
> custom deletion semantics?

I haven't followed your discussion closely, so I may have the wrong idea, but don't you run the risk of mixing the different ref counting techniques on objects of the same type?  If the ref counting scheme isn't part of the smart pointer type, then all instances must do ref counting the same way.

IOW, if all instances are my_ref_counter<T>, then having some manipulate the ref count of T's one way and others doing it another means that you can reference the same T instance from different my_ref_counter<T>'s which can manipulate the ref count differently.  Put that in context of thread safety and you can see how a non-thread safe my_ref_counter<T> can wreak havoc on thread code that expects a T's ref count to be manipulated by thread safe my_ref_counter<T>s.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.