http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48848
--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-05-03 11:18:28 UTC --- (In reply to comment #12) > I think I see what you mean, but actually, I'm not sure that this kind of > sophistication would be consistent with the rationale of LWG 675: if I It definitely wouldn't - but do the general container requirements apply to valarray? if not, 675 is irrelevant (I think it is relevant and 675 should have removed the constant complexity requirement for valarray's move assignment op) > understand it correctly, we really want the move-assigned-to object to behave > similarly to the copy-assigned-to object, thus destruct and release > immediately, no? We want the moral equivalent of this->clear() & > this->swap(__other). I agree that makes sense. My suggestion about delaying deallocation only makes sense if we want to implement the letter of the FDIS and have constant complexity for valarray move assignment (in contrast with other containers) - but let's get clarification on whether 675 should have been applied to valarray too
