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