Jan Gaspar wrote:
4. Type Requirements: don't T need to be Assignabletoo? Just no!
Then how is an element overwritten? Look at the replace() method in the source code.
This strikes me. All standard containers require T to be Assignable, so I don't understand the rationale for dropping such requirement. Does it give more freedom? Perhaps yes, but not so much IMHO. Users of containers are probably going to provide assignment anyway. Suppose that T *is* assignable, is destroy+copy construction better than assignment? Probably no, for several reasons, including: 1) assigment is probably more efficient. In particular it might avoid destruction/reconstruction of sub-objects non related with the class invariant (for example: buffers, mutexes, etc.). 2) with the dtor/ctor idiom, if the ctor throws an exception, the old element is lost and you can't do anything about it, so the container cannot provide more than the basic guarantee for any method that might overwrite elements. However, the user might implement assigment with the strong guarantee, the container might leverage on that and provide the strong guarantee too at least for methods that might overwrite a single element such as push_back/push_front. (Of course, the user might implement assignment so badly that it doesn't provide even the basic guarantee and the container could not recover from that, but a library such not try to outsmart the user... too much ;). Just my opinion, Alberto