Regarding thread_specific_ptr's non-moveability
thread_specific_ptr is currently (Boost 1.59) not moveable, since it defines a user-declared destructor and in addition (privately) user-declares the copy special member functions. Is this decision by design, or simply not yet updated to move semantics?
From what I can tell, a move should be possible along the lines of:
auto* p = other.release(); // without invoking other's cleanup fn reset(p); // potentially differente cleanup fn associated The only problematic situation I can think of is a scenario with two semantically different custom cleanup function where a move eventually triggers only the second one. But this is behavior is consistent with move semantic. Cheers, Daniel J H References:
http://www.boost.org/doc/libs/1_59_0/doc/html/thread/thread_local_storage.ht...
Le 15/12/2015 16:19, Daniel Hofmann a écrit :
thread_specific_ptr is currently (Boost 1.59) not moveable, since it defines a user-declared destructor and in addition (privately) user-declares the copy special member functions.
Is this decision by design, or simply not yet updated to move semantics? I believe no one thought about that. Please could you create a Trac feature request ticket? I will try to see what ca be done.
From what I can tell, a move should be possible along the lines of:
auto* p = other.release(); // without invoking other's cleanup fn reset(p); // potentially differente cleanup fn associated
The only problematic situation I can think of is a scenario with two semantically different custom cleanup function where a move eventually triggers only the second one. But this is behavior is consistent with move semantic.
Please, be ass concrete as possible on the ticket description. I have no time until the new year to look at this. Best, Vicente
participants (2)
-
Daniel Hofmann -
Vicente J. Botet Escriba