Re: [boost] [utility] auto_buffer v2

Subject: Re: [boost] [utility] auto_buffer v2
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2009-03-05 03:56:19

Matt Calabrese skrev:
> 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. 

Thanks.

>Is there a reason why you assert ( this != &r ) in the
> assignment operator? Certainly this case could be handled by just returning
> *this, right?

Yes. I must admit I always disliked the discussions on "assignment to 
*this". I never personally created code that would run into such cases.
So I put the assertion there because I don't want to use cycles on this 
case. I think it is hypothetical.

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

Right. That is mainly why I added copy-operations.

> This means
> the function "is_on_stack" may be better named "is_stored_locally" or
> something similar.

Maybe, I'm not sure.

> 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

Remark: boost::any desparately needs SBO.

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

I guess it is a bit like some people talked about when they referred to
allocators with an embedded stack buffer.

As one can see from my code, swap and copy-operations are difficult to 
implement. Especially swap. Therefore such an allocator will be *very* 
difficult to use correctly in a container. In particular, swap() 
sometimes only gives the basic guarantee (and no better guarantee is 
possible!).

The partially stack-based allocator works fine if the container is used 
locally, but seems very problematic for general use-cases.

-Thorsten