Re: Some questions on allocators and shared_ptr

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

On 17 October 2010 15:38, Alex Dubov wrote:
> Jonathan Wakely <jwakely.gcc <at> gmail.com> writes:
>
>>
>> Right, which makes me more certain shared_ptr isn't ideal for this purpose.
>>
>> The second count kept for weak_ptr support isn't needed, and
>> shared_ptr only needs to allocate memory to support the weak count as
>> a separate object. ?If you don't need that feature, adding
>> non-standard extensions to workaround it's consequences seems wrong.
>>
>> I would stick to a design without shared_ptr, storing an allocator and
>> (intrusive) reference count in the nodes.
>>
>
> I was under an impression, that having multiple implementations of reference
> counts is not the best idea around (as of now, existing rope, basic_string and
> vstring all have it manually implemented).

I agree it would be much better to have a single implementation for
each use, so sharing code between strings makes sense, but I don't
think having a single implementation for all uses makes sense.
shared_ptr has two counts, which is very different to other uses.

> I will probably try to make use of Sp_counted_base directly, saving myself at
> least part of the trouble (and may be I'll find a use for weak_count as well).

Cool, but I hope you see why I object to adding extensions to
shared_ptr to make it work for a use-case which it doesn't really
suit.  I think it would be better to write a new refcount type with
only one count (no weak count) which could be shared by rope and
vstring (we will not change the current basic_string impl now, not
until we replace it with a non-refcounted string)