Re: Some questions on allocators and shared_ptr

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

On 16 October 2010 14:24, Alex Dubov wrote:
>
> The problem with any template<int N> solution is that in general case you don't
> know the length of string you want to allocate in advance. One approach,
> loosely implemented in other containers, is to work with a collection of sizes,
> always allocating blocks of 2^N size and storing a "capacity" parameter
> together with "size". This reasonably limits the number of implicit sizes to,
> maybe, a dozen (3 < N < 15).

Yes, that's what I was thinking.

> For rope<> it is plain wasteful, because it almost never augments existing
> buffers (unlike basic_string or vector), being more functional in this respect

That's a good point.

> (new sub string == new value). Besides this, rope is not the only string
> processing class implemented in this fashion. "Pascal-like" strings are very
> common, yet there's no library support for things like:
>
> struct pstring {
> ? ?metadata foo;
> ? ?_CharT buf[]; // array of run-time deduced length
> };
>
> For uses like:
>
> auto ptr(shared_ptr<pstring>(allocate<pstring1>(size), pstring1_deleter);
>
> the second allocation happens inside shared_ptr constructor.

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.