Some questions on allocators and shared_ptr

[Alex Dubov]

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).