on Thu Jan 31 2013, Paul Smith <pl.smith.mail-AT-gmail.com> wrote:
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,
I was disavowing this part because I don't claim to know it for sure:
it's not something the standard actually guarantees in general, though, and the requirements are still much stricter, perhaps superfluously so.
and I was disavowing this part because I disagree with it:
it's a good selling point for having destructive move semantics -
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?
See above.
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".
Right. And that's the resolution I fought for.
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.
I agree, it would be. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost