Re: [Boost-users] [Boost.AutoBuffer] discussion

Subject: Re: [Boost-users] [Boost.AutoBuffer] discussion
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2013-05-06 08:28:34

On 06-05-2013 09:22, John M. Dlugosz wrote:
>
>> I recall some "detail" code in Boost that does exactly what I want:
>> allocate a probably-good-enough size on the stack but switch to heap if
>> needed. But I can't remember where I saw it.
>>
>> Looking around, I came across mentions of Boost.AutoBuffer by Thorsten
>> Ottosen, but all links are dead.
>>> I have been a bit  busy, but I plan to get it going soon.
>>>
>>> It seems that there is an unofficial version in
>>>
>>> boost/signals2/auto_buffer.hpp
>>>
>>> regards
>>>
>>> -Thorsten
> Thanks.  I found that copy, and it had your name on it too, so I figure
> it must be the same code.

>
> However, I think the existing public API could be improved a little in
> this manner.  Here is what I ended up doing:
>      auto_buffer<wchar_t> buf;
>      buf.uninitialized_grow (buf.capacity());  // start out with as much
> as fits on the stack (256 elements).
>      int result= ::GetWindowTextW(hWnd,buf.data(),buf.size());
>
> I had to figure out that capacity was the correct way to get the
> stack-based size, but that's a documentation thing.  I called
> uninitialized_grow rather than uninitialized_resize because I know it
> was originally zero; the passing of the delta which looks like the new
> size too bothers me a little.  But my real point is that I can't command
> an uninitialized size on the constructor.  The normal constructor
> arguments work the same as vector, and can take an initial size and a
> value that defaults to T().  It would be much clearer and simpler for
> this use case to say what I want directly on the constructor.  I think
> it would be natural to give a special flag where the value would
> normally go:
>      auto_buffer<whcar_t> buf1 (500 /*count*/, L' ' /* value */);  //
> same as std::vector
>      auto_buffer<wchar_t> buf2 (500, non_initialized);  // looks like a
> "value", but overloaded ctor.
> and it would be unambiguous to give the non_initialized flag alone,
> taking the maximum pre-allocated size.
>      auto_buffer<wchar_t> buf3 (non_initialized);

My newer version has more explicit control of the initial constructed 
object.

> Meanwhile, should the class support uninitialized sizing ONLY for types
> that support it? That is, PODs, primitives, classes without destructors,
> and in general those that are marked as such via a metaprogramming type
> trait.

No, uninitialized grow/shrink/resize is needed for efficient in-memory 
serialization of arbitrary types. It's tempting to ban this, but it 
rules out good use cases.

-Thorsten