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

Subject: Re: [boost] [utility] new auto_buffer class --- RFC
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2009-03-02 12:07:21

On Mon, Mar 2, 2009 at 10:29 AM, Thorsten Ottosen <
thorsten.ottosen_at_[hidden]> wrote:

> Alternatively we might try to compute a reasoable default size
> based on the size of the type and based on minimum and maximum default
> sizes.
>

Agreed. Especially in terms of providing a meaningful default, the amount of
bytes being used up on the stack is much more of a concern than the number
of individual objects on the stack. In retrospect, it might even make sense
for the template parameter to be in bytes rather than object count.

Concerning your implementation there is at least one major issue I have --
your use of "optimized_const_reference." You define
optimized_const_reference to be a const value_type if the value_type has a
trivial assignment operation. You then return this from const accessors such
as front, back, and operator []. While it first this might seem like a
clever trick, it is flawed in several subtle ways. Firstly, it is not
necessarily optimized because the object may be considerably large, implying
you'd be making a copy of a large object simply by calling operator [], but
aside from that there are much more important reasons why you should avoid
this.

Unless I am mistaken, it makes your container not a valid STL container,
although it already has an O(n) swap which is unavoidable. But the main
reason why I consider this a fault is that it now means that if you store a
pointer/reference to an element in the array taken from a non-const accessor
it will not reference the same object as what is returned from a const
accessor which can cause obvious subtle issues (and it means you cannot get
a pointer to an element in the array when all you have is a const reference
to the container unless you use "data")! It also means that you cannot
directly take the address of the values returned from your const accessor
functions in cases where the type contained has a trivial assignment
operation since you can't directly take the address of a temporary.

All of this is avoided by simply returning a const_reference to the
contained object, and it makes the behavior for your template consistent
between different instantiations, not to mention with containers in the STL.
While the optimized_const_reference trick is clever, I do not believe it is
appropriate here.

-- 
-Matt Calabrese