On Thu, Jan 31, 2013 at 3:22 AM, Dave Abrahams <dave@boostpro.com> wrote:
on Mon Jan 28 2013, Paul Smith <pl.smith.mail-AT-gmail.com> wrote:
This issue has been discussed more than once before, and nothing I say here is my own opinion, so please don't take it out on me. For example, see N3264 (CH-18 and US-85: Clarifying the state of moved-from objects (Revision 1)):
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3264.htm
and Dave confirms that,
I don't want to read into what Dave said too much, because he's here and he can clarify it. But I believe what he said is that specific algorithms, in their own localized context, practically only require destructibility and assignability. And even then, it's not something the standard actually guarantees in general, though, and the requirements are still much stricter, perhaps superfluously so. That's frustrating, no doubt about it, and it's a good selling point for having destructive move semantics - not for breaking the rules.
That doesn't sound like anything I meant to say, but I do agree fully with the resolutions (if not the NB comments) in the paper cited above.
Then what did you mean? I was responding to Joel's claim:
The standard only mentions assign and destroy as necessary, and Dave confirms that
He refers to you answer:
(The) ability to both assign and destroy? Is that all that it needs? That's all the standard library will use.
But the library's requirement from moved-from user-types, as of this paper's resolution, is stricter. In [moveconstructible]: rv’s state is unspecified [ Note:rv must still meet the requirements of the library component that is using it. The operations listed in those requirements must work as specified whether rv has been moved from or not. —end note ] Nowhere does it say anything about just being destructible and assignable. Btw, the reason why I brought up this paper was because I couldn't help noticing the similarity between the case mentioned there and what we have here. The US NB was requesting that the standard would require standard-library types (or maybe types in general) only to be destructible and assignable after a move. The case they mentioned was containers that allocate their sentinel nodes dynamically. If the container has to remain valid after a move, the move constructor has to allocate sentinel nodes "for nothing". The resolution was, AFAICT: No. Moved-from library types should remain valid. If dynamically allocated sentinel nodes are your implementation strategy, you have to bite the bullet (Which is, btw, what the Microsoft implementation actually does, at least as of MSVC 10. Could someone please check if they changed it in 11? Run the attached file, you should see two allocations). The resolution wasn't "let's say that moved-from types should only remain destructible and assignable", and it wasn't "let's add a singular value to std::list". Ofcourse, boost isn't the standard library and you're not bound by any of this. Still, it's awkward to have the standard pull in one direction and boost pull in the other one. -- Paul Smith