Re: Some questions on allocators and shared_ptr

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

On 18 October 2010 20:02, Alex Dubov <oakad@yahoo.com> wrote:
> Jonathan Wakely <jwakely.gcc <at> gmail.com> writes:
>
>> >
>> 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)
>>
>>
>
> This still leaves an open question of how to handle the types without compile
> time sizes. One approach is to use intrusive counts, as discussed above, but
> those have some disadvantages. And then, boost::intrusive_ptr already
> implements this sort of functionality, so it may be worthwhile to just borrow
> it as is (it's written by the same author as shared_ptr, so, I suppose, it
> wouldn't pose a problem).
>
> On the other hand, non-intrusive pointers are more convenient, if they provide
> a way to specify this "extra" storage in special cases. My preference, if there
> are no other considerations, is to implement the variety of counted pointer
> described in my original post, the one implementing T *get(), Alloc
> *get_alloc() and void *get_extra(), and otherwise being more or less a
> simplified copy of existing shared_ptr. This will allow for the minimal
> possible work on behalf of common user classes (rope, for instance, has 4
> internal helper classes, of which only the "leafs" have to store arbitrarily
> sized strings).

I think that sounds like a good plan.

Thanks for your interest in improving rope!  Do you have a GCC
copyright assignment in place?

Jonathan