Re: vc 2010 beta2 bind unique_ptr move
nebojsa vujnovic wrote:
I'm playing with new language features and as a result:
win32 console app->empty project
file: main.cpp
#include <memory>
#include <functional>
#include <utility>
void foo(std::unique_ptr<int> pint)
{
}
int wmain( )
{
std::unique_ptr<int> pint(new int(42));
std::bind(foo, std::move(pint));
}
1>main.obj : error LNK2001: unresolved external symbol "public: =
__thiscall
std::unique_ptr<int,struct std::default_delete<int> =
::unique_ptr<int,struct
std::default_delete<int> >(class std::unique_ptr<int,struct
std::default_delete<int> > const &)"
(??0?$unique_ptr@HU?$default_delete@H@std@@@std@@QAE@ABV01@@Z)
The functional produced by std::bind stores a copy of pint (which it can =
do using move constructor). Its operator() would then call =
foo(copy_of_pint). It doesn't know enough about its parameter to infer =
that it should use move() in this call. So this is the part that fails.
The (draft) standard requires that parameters of std::bind be =
CopyConstructible, which unique_ptr isn't. So your program is invalid.
I expected that move constructor is called not copy constructor and I =
also
expected that move
constructor will be called when callee is invoked.
What led you to expect the latter?
Will it be possible to transfer ownership to callee using bind, =
unique_ptr,
move combination ?
Not as far as I can tell. Why would you need a functional that can be =
called only once?
And does C++1x say anything about this
Yes.
or is it a VC bug
No.
or I expect too much?
Apparently.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not =
necessarily a good idea. It is hard to be sure where they are going to =
land, and it could be dangerous sitting under them as they fly overhead. =
-- RFC 1925