On Thu, Jan 31, 2013 at 9:24 AM, Antony Polukhin <antoshkka@gmail.com> wrote:
From theoretical point of view you are absolutely correct, and my example is lame. Moreover, current implementation of move assignment and move constructors for recursive_wrapper were implemented to model that behavior.
Just pointing out that move assignment is not affected by this discussion. Everything is already allocated so it's as efficient as a pointer swap.
But I do understand Joel's efforts to make it faster.
[snip]
Allowing destructive move constructor for recursive_wrapper will make variant at least 3 times faster.
Oh, I never said otherwise, and I definitely sympathize with the desire to make it faster :-) What I'm saying is that this sort of tradeoff was taken into account when move-semantics were designed, and it's awkward to retroactively go against that.
Leaving recursive_wrapper as is will provoke users to use a really slow implementation.
Well, it's not like the introduction of move semantics made existing code slower all of the sudden :-)
Unique_ptr and other types can not be used as a drop in replacement for recursive_wrapper.
That's right, although since they have different semantics, it's not necessarily a bad thing.
May be we shall deprecate recursive_wrapper and add recursive_ptr/nullable_recursive_wrapper class, that implements destructive move constructor? It does not break recursive_wrapper invariants,but adds a class with different invariants.
I don't think we should deprecate anything. But adding a type with different semantics (in addition to option III which is always a good idea) is definitely far better than changing recursive_wrapper. Let each user pick their own poison. -- Paul Smith