Re: Some questions on allocators and shared_ptr

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 21 October 2010 19:57, Alex Dubov wrote:
>>
>> Thanks for your interest in improving rope! ?Do you have a GCC
>> copyright assignment in place?
>>
>
> No, I don't have any, and the instructions look fairly confusing.

The process can take a long time, so it's worth starting it ASAP if
you do plan to contribute.

> I wrote a preliminary version of the "counted_ptr" class, implementing the
> discussed functionality. Shall I post it to the list as is? For now, it can be
> seen here: http://github.com/oakad/mx2sphinx/raw/devel/rope/counted_ptr.h
>
> Major departures from shared_ptr are:
> 1. counted_ptr has only one member, which is the held object pointer itself.
> 2. To make p.1 possible, no raw pointer constructor is provided, only
> make_counted and allocate_counted. Given that variadic argument forwarding is
> here to stay, I presume, it's a reasonable price for fast dereference
> operation.
> 3. I'm using pointer arithmetic to get to the enclosing refcount object from
> the held object pointer.
> 4. Variants of allocate_counted and make_counted are provided, which allow to
> specify an "extra" byte storage to be allocated together with the held object.

That all sounds good.

> 5. Allocator is only optionally stored and even then, only in the form of base
> (empty object optimization pattern). Here I also wonder, why there's nothing
> like boost::compressed_pair in the library? It'll surely be nicer than various
> alloc_hider classes around the place.

Most of those classes predate boost::compressed_pair by some years,
and haven't been changed because they work fine, and changing it would
not be backwards-compatible.

IIRC our tuple works like a compressed-pair, but with any number of
elements, Paolo suggested using it in shared_ptr and I intend to look
into that. Again, our shared_ptr code predates our tuple
implementation, which is why it wasn't done that way originally.