From: Daniel Frey (d.frey_at_[hidden])
Date: 2008-04-25 03:09:15
On Thu, 2008-04-24 at 23:23 -0400, Frank Mori Hess wrote:
> On Thursday 24 April 2008 21:22, Daniel Frey wrote:
> > On Wed, 2008-04-23 at 23:20 +0200, Daniel Frey wrote:
> > > Peter, shall I write a patch for the documentation for
> > > get_shared_count() and the new ctors? Or would you like to take care
> > > of that?
> > I prepared a patch for the documentation. While doing that, I noticed
> > that the current ctor is a template ctor, which it should not be. Is:
> What's the point of documenting an unspecified reference counter type?
> Following the interface specified by the docs, the only thing you can do
> with get_shared_count() is pass its return value directly to the
> constructor that takes a shared_count. That adds nothing over the
> aliasing constructor. You can't store the return value in a shared_count,
> because it's an unspecified type.
Peter suggested to call it get_shared_count() instead of
_internal_shared_count(), so I figured that this is going to be a
documented public interface. I personally prefer it over the existing
aliasing ctor, but when I suggested to remove the aliasing ctor, Peter
said he is not interested in that.
Even if the existing aliasing ctor remains, the new interface provides
an alternative. And one that I would definitely prefer, I'd rather write
x.reset( y.get_shared_count(), z );
x.reset( y, z );
in my user code (likewise for ctors), since it is more explicit and IMHO
communicates better what it does. Aliasing will probably not be used
very often, but if it is, it's easier to spot and you can easily grep
Looking at the name, I realize that get_shared_count() might not be the
best choice. We already have use_count() so get_shared_count() might be
misleading. Maybe get_reference_counter()?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk