"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> 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