[boost] Re: Formal Review: Circular Buffer

From: Alberto Barbati (abarbati_at_[hidden])
Date: 2004-03-07 21:01:32

Jan Gaspar wrote:
> I agree the assignment is more efficient. If you dig
> in the code little bit you will find that there is
> assignment operation provided for the primitive types.

That is good. However, I think that such optimization is unnecessary. 
For primitive types, the destructor is trivial and the copy constructor 
is the assignment, so I bet a reasonably good compiler can optimize the 
dtor/ctor idiom to a simple assigment even without any "help" in the 
form of template machinery. Besides, bad compilers may introduce 
pessimizations... ;)

> The idea behind the dtor/ctor idiom is like this:
> suppose you have full circular_buffer and you want to
> push_back a new element (instance of some class). That
> means the fron-most element is about to be
> overwritten. Now if there will be the assignment idiom
> applied the front-most will be assigned to the new one
> - it will be not destroyed (no destructor will be
> called). IMHO this is not correct. The old element
> will not disappear - just its value/state will be
> different. I think that the overwrite operation means
> destruction of the old object, NOT assignment. What do
> you think?

That's interesting, indeed. I agree it is more "correct". However, I 
don't see this improved correctness bringing a real benefit to the user. 
Do you have at least one use case where the ctor/dtor idiom can be 
leveraged by the user in order to provide a feature not obtainable with 
plain assignment?

BTW, this discussion triggers some other ideas. Have you considered 
adding to the circular_buffer the capability to optionally notify the 
user about an impeding overwrite? I have at least one use case where it 
might be useful. It might be as easy as invoking a boost::function0 
callback, at the cost of few bytes in footprint and an extra test before 
any overwrite. Alternatively, we could put hooks (in form of a template 
policy, for example) in the main container that are then implemented by 
a container adaptor, so the user won't pay if it doesn't want such a 
feature.

Alberto