On Mon, Jan 28, 2013 at 6:11 PM, Joel de Guzman <djowel@gmail.com> wrote:
On 1/28/13 10:10 PM, Paul Smith wrote:
On Mon, Jan 28, 2013 at 2:02 AM, Joel de Guzman <djowel@gmail.com> wrote:
I think we are OK!
Come to think of it, the situation is a lot like a "singular" iterator:
"Iterators can also have singular values that are not associated with any sequence. [snip] Results of most expressions are undefined for singular values; the only exceptions are destroying an iterator that holds a singular value, the assignment of a non-singular value to an iterator that holds a singular value, and, for iterators that satisfy the DefaultConstructible requirements, using a value-initialized iterator as the source of a copy or move operation."
Indeed, for a singular valued iterator, i, you can assign to i and destruct i, place i in a container, etc. You just cannot dereference i, access its underlying value through ->, compare i with another iterator, etc.
The same is true with a nulled recursive_wrapper.
Being honest about this is just a matter of documentation. I do not see any problem at all with having a "singular" recursive_wrapper value.
Then you're still thinking in terms of destructive move. The reason why you don't see a problem with a "singular valued" recursive_wrapper (that's what we call it now? :-) is that you don't think anyone will try to use it. And, c'mon, it's not just a matter of documentation - we're not trying to weasel our way out of this. Adding a new and entirely different state just for the sake of move construction is a polite way of ignoring the possiblity that moved-from objects will be used. It might win you a case in court, but it's completely missing the point.
Besides, drawing from iterators to recursive_wrappers is dangerous. They're completely different things. A recursive_wrapper's value *is* its underlying object's value - it's not a pointer. Talking about "singular values" under this concept doesn't make sense.
If you want a recursive_wrapper that has an empty state, that's fine. But it's a different concept that deserves a different type.
Oh man, here we go again.
Sorry, I didn't mean to be irritating. I'm honestly not trying to spite. If this discussion gets heated, I quit.
No I am not convinced. Sorry. The standard only mentions assign and destroy as necessary
Really, where? [moveconstructible] has much stricter requirements than that. 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.
as did people like Stanley Lippman (C++ Primer 5th Edition).
I didn't read the book, but as you see, there's a lot of controversy and misconception around this subject, so I'll take everything with a grain of salt. If you have a quote, that would be helpful.
I am also not convinced that drawing from objects with "singular" values is wrong, regardless if it's a pointer or not. I think it is you who's missing the point because Iterators are likewise *not* pointers.
Okay, so replace "recursive_wrappers are not pointers" with "recursive_wrappers are not iterators". How does it make it any different? A singular value still doesn't fit in. -- Paul Smith