Re: [boost] Proposal to add smart_ptr to the boost library

From: David Maisonave (boost_at_[hidden])
Date: 2006-01-31 05:09:17

"David Abrahams" <dave_at_[hidden]> wrote in message
news:<8764o1azuq.fsf_at_[hidden]>...
> "David Maisonave" <dmaisonave_at_[hidden]> writes:

> >> IIUC, the thread-safety problem with reference-linked 
> >> implementation
> >> isn't that so much that it's hard to achieve -- anyone can use a 
> >> shared mutex -- it's that it's hard to make a thread-safe 
> >> implementation efficient.  That is to say, you pay for the cost of 
> >> locking and unlocking a mutex, and there's no way around it (**).  
> >> Locking and unlocking mutexes is way more expensive than performing 
> >> the lock-free operations used by boost::shared_ptr.
> >
> > That's true.  But it's been my experience that the majority of 
> > development don't have objects access via multiplethreads or don't 
> > run in a multithread environment. In this environment, you're paying 
> > additional price for using boost::shared_ptr reference-count logic, 
> > but not getting any benefits from it.
> 
> Not if you're compiling without mt support on; the thread safety 
> features of shared_ptr just compile away (and I think there's a macro 
> you can use to force them off).  Let's compare apples to apples: your 
> reflinked implementation will be slower in a MT environment.  I'm not 
> yet convinced it will be faster in a ST environment unless you leave 
> the MT features of shared_ptr turned on.

Currently, my test results don't support your above comment.
Please provide the this macro you're referring to.
Without this macro, there's no way of testing your claim.