Some questions on allocators and shared_ptr

[Alex Dubov]

Jonathan Wakely <jwakely.gcc <at> gmail.com> writes:

> >
> > Is it possible/feasible to add the functionality described above as an
> > extension to the library?
> 
> It would be possible, but it shouldn't be needed. Can you use the
> aliasing feature of shared_ptr to make it unnecessary?
> 
> template<int N, typename Ch>
> struct rope_storage {
>     std::array<N, Ch> data;
>     rope_node node;
> };
> 
>  auto raw
>   = allocate_shared<rope_storage<64, char>>(A,...);
> 
> shared_ptr<node> node(raw, raw->node);
> 
> Could you use something like this?
> 
> 

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

For rope<> it is plain wasteful, because it almost never augments existing
buffers (unlike basic_string or vector), being more functional in this respect
(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.