[boost] Re: Formal Review: Circular Buffer

From: David Abrahams (dave_at_[hidden])
Date: 2004-03-08 16:33:35

"Pavel Vozenilek" <pavel_vozenilek_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote
>
>> No, I'm saying that their values can go away without destruction: you
>> could replace their values in the buffer using assignment instead of
>> destroy + construct.  There's no a priori reason they have to be
>> destroyed.
>>
>> When I erase objects from a std::vector, the objects being erased
>> don't neccessarily get destroyed.  They may be assigned.  For
>> example, here's STLPort's vector<T>::erase(iterator) implementation:
>>
> [snip code]
>>
>> Notice that only the last element of the vector is destroyed.
>>
>
> Quoting from similar discussion on c.l.c++.m: http://tinyurl.com/2c3na
>
> --- quote about vector::erase ---
> The standard says this:  "The destructor of T is called the number of
> times equal to the number of the elements erased, but the assignment
> operator of T is called the number of times equal to the number of
> elements in the vector after the erased elements."
> ------------------------------------
>
>
> With circular buffer the destructor wouldn't be called at all,
> in similar circumstance.
>
> Eample:
>    Circular buffer of size 3.
>    You create 100 of objects and push them in.
>     You would get:
>       - 100 constructors called,
>       - 97 copy constructors called,
>       - 3 destructors called.

Yeah, but my point is: so what?

I still see no a priori reason that circular_buffer must do element
destruction before it is itself destroyed.  std::vector *has* to do
some destruction in order to get the right semantics.  Arguably,
circular_buffer does not.  If it doesn't matter *which* vector
elements get destroyed upon erase, then I presume it doesn't matter
which circular_buffer elements get destroyed.  In that case, why
should it matter that any elements are destroyed?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com