Re: [boost] [utility] new auto_buffer class --- RFC

Subject: Re: [boost] [utility] new auto_buffer class --- RFC
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2009-03-02 09:23:37

Beman Dawes skrev:
> On Sun, Mar 1, 2009 at 4:04 PM, Thorsten Ottosen
> <thorsten.ottosen_at_[hidden]> wrote:
>> Dear all,
>>
>> For a long time I have been missing this utility in my own work, and in
>> boost related stuff too. I think there are a number of libraries in boost
>> that can benefit from this utility. Libs like boost.format can be quite a
>> bit more effective. So can logging libraries. etc.
>>
>> ...
>>
>> Comments are most welcome.
> 
> I think auto_buffer would be a very useful addition to Boost.
> 
> A few quick comments:
> 
> * Move the comments about VLA's and differences from
> stlsoft::auto_buffer to a "Design History" (or similar) section of
> documentation. They just confuse readers who don't know anything about
> VLA's or have access to Matthew's book.

Good idea. I should have written some docs, but I just wanted to hear if 
there is interrest.

> * Rename N to something more explicit. MaxStackElements perhaps?

Good idea.

> * It looks like auto_buffer would often be preferable to
> boost::scoped_array. Or am I missing something?

No.

There is one thing that could make boost::scoped_array<T> (and
scoped_ptr<T> for that matter) occupy a slight niche. There is
no general way to give up ownership of the buffer inside
boost::auto_buffer<T> because it might be on the heap, or it might be on 
the stack. If boost::scoped_array<T> added a release() member function 
it would occupy that niche. release() is really useful to have when 
dealing with legacy code, so I have been unable to understand why it is 
not there in the first place (and yes, I understand the encapsulation 
concerns, but much prefer usability when we have to choose one of them).

-Thorsten