Boost logo

Boost :

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:
> --- 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at