Subject: Re: [boost] [move] You can do it better: implementing push_back and handling implicit conversions
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2011-03-08 19:54:44
[Ion Gaztañaga]
> Problem: MSVC 10.0 (Visual 2010) with real rvalue references seems to have
> bugs and does not compile the test.
I don't think that the compile error of MSVC 10.0 triggered by the statement
container<conversion_target_movable> c;
is entirely unique to version 10.0, it's only triggered more frequently (and especially I think it is completely unrelated to rvalue references). IIRC, the same compile error will be triggered by the following code
class __declspec(dllexport) derived_class : public container<conversion_target_movable>
{
...
};
in earlier versions of MSVC. I think that this error is caused by MSVC instantiating every single non-template member function of the "container<conversion_target_movable>" class, whether it is actually used or not. I have to admit that I understand why MSVC does this in case of __declspec(dllexport). However, triggering the same behavior by the statement "container<conversion_target_movable> c;" probably really qualifies as bug.
> I can't find a workaround, a future
> Service Pack might solve these errors, but maybe we should stick to
> emulation code in this compiler, unless someone could shed some light on
> this, of course.
As I think this is unrelated to rvalue references, I don't see how sticking to emulation code should help with this.
A workaround for your example is to turn the non-template member function into a template member function to avoid that MSVC 10 instantiates the member function which is not applicable to non-copyable element types.
template<class TT>
void push_back(BOOST_MOVE_CATCH_CONST(TT) x)
{ return priv_push_back(static_cast<const TT&>(x)); }
A more challenging workaround would be to selectively deactivate all non-applicable member functions by meta-programming.
[Stephan T. Lavavej]
> Can you provide a minimal test case, demonstrating just the bug in question?
Is the above description of the issue clear enough, or do you still need an explicit minimal test case?
Regards,
Thomas