Re: Storing noncopyable but movable object in std::function
On 2011-11-04 00:50, Marc wrote:
unless you would be willing to standardize a type that *declares* a
copy-constructor/assignment operator (and similar for the move
operations), but might simply throw an exception "sorry, guys, my
internals just tell me that I cannot copy". This will break all static
deduction tools like std::is_copy_constructible (which say "yes, we
can"), until the runtime tells us something different. I don't think
that this would be a good idea.
I thought those static deduction tools were fairly unreliable to begin
with. I just checked on this simple example that a pair of move-only
types is reported as copy-assignable by g++, which blindly follows
the standard definition of std::pair. Actually assigning will result
in a compile-time error and not a runtime one though.
#include<utility>
#include<iostream>
#include<iomanip>
#include<type_traits>
struct A {
A(){}
A(A const&)=delete;
A(A&&){}
};
int main(){
std::cout<< std::boolalpha;
std::cout<< std::is_copy_assignable<std::pair<A,A> >::value<< '\n';
std::pair<A,A> a,b;
// b=a;
}
This is true for this example, but there is still a difference in regard
to the implications for std::function, because in this case both the
trait deduction *and* the assignment expression that instantiates the
*implementation* of the pair copy assignment operation would be
well-formed, but the copy would fail during runtime.
Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]