From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-04-26 18:15:39
From: "Howard Hinnant"
> On Apr 25, 2004, at 9:29 PM, Peter Dimov wrote:
>
> > In fact, it isn't even clear to me why you need to synchronize access
> > to the
> > implementation at all, as std::locale is immutable; it has no non-const
> > member functions.
>
> Ah, I think I see the confusion. locale is mutable. The copy ctor
> mutates the rhs (though not visibly) and the assignment mutates both
> sides. There's more refcounting running around under locale's hood
> than just the shared_ptr to the implementation. In addition each facet
> is individually refcounted (but not with shared_ptr). Even
> std::use_facet potentially mutates a locale (via lazy addition of a
> standard facet to the locale).
Yes, I see. It isn't very common for a class to physically (but not
logically) mutate the rhs on copy. ;-) But I agree that in this case you'd
gain nothing from separate count synchronization. Let's go a bit further.
The obvious alternative to shared_ptr here, to me, is not a non-synchronized
shared_ptr, but an embedded reference count (no need for separate count
synchronization -> no need for separate count). Is there something else that
I'm missing that makes intrusive counting unsuitable?