Re: [boost] [utility] auto_buffer v2

Subject: Re: [boost] [utility] auto_buffer v2
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2009-03-04 20:48:35

On Wed, Mar 4, 2009 at 6:54 PM, Thorsten Ottosen <
thorsten.ottosen_at_[hidden]> wrote:

> Dear All,
>
> Hereby an updated class. Thanks to all who contributed with comments to the
> first try.
>
> ...
>
> Comments most welcome!
>

Looking good. Is there a reason why you assert ( this != &r ) in the
assignment operator? Certainly this case could be handled by just returning
*this, right?
Also, the more I think about it, we have only been looking at this as
strictly for use on the stack, but nothing prevents someone from using it as
a global, or for instance, as a datamember of a type that may not be
instantiated on the stack, which may be beneficial as well (or at the very
least, nothing prevents someone from using it in such a manner). This means
the function "is_on_stack" may be better named "is_stored_locally" or
something similar.

Just to throw it out there as something to consider, I could definitely see
a generalization of this idea not specific to array allocation also being
very useful. By this I mean, a template similar to what you have now but
dealing with raw memory without a container interface and no stored type
specified -- it would just let you do a raw "resize" (or "reallocate"). When
the requested size is under N, accessing the data gives you a pointer to the
locally stored buffer, otherwise it is to dynamically allocated memory
managed by the type, much like auto_buffer. The main use-case I see for this
would be as an implementation detail internal to an "any" or "function" or
"poly" kind of type to allow objects under a certain size to be stored
directly in the type in which it is contained rather than dynamically,
resorting to additional allocation only when necessary. Instantiating the
template with a different value for N would in effect control how large of
an object could be stored locally before having to resort to an additional
allocation.

I'm not implying that you should implement this, just that it is something
to think about. The implementation would be extremely similar and it even
seems like the former may be able to be implemented via the latter.

-- 
-Matt Calabrese