Re: [boost] [move] You can do it better: implementing push_back and handling implicit conversions

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-09 03:56:59

[STL]
> Can you provide a minimal test case, demonstrating just the bug in question?

[Thomas Klimpel]
> Is the above description of the issue clear enough, or do you still need an explicit minimal test case?

[STL]
> The latter, please. I just need a tiny source file with as little extraneous machinery as possible,
> a command line, its output (so I can verify that I'm seeing what you're seeing),
> and a description of what you expect should happen (with Working Paper citations if you want to be super helpful).
> Then I can figure out what's going on myself, or route it to the compiler team.

Find attached a test case showing the scenario I described.
However, it turns out that I was mislead by the error message when I wrote

> 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).

because the "non-applicable member function" is actually explicitly used/called some lines below the statement that the compiler claims to be the offending one. So putting aside the question whether the "non-applicable member function" should actually be applicable because of some tricky standard wordings, one bug here is that the error message emitted by the compiler doesn't contain the line number of the offending statement, but only the line number of the declaration of the variable later used in the offending statement.

> IIRC, the same compile error will be triggered by the following code
> 
> class __declspec(dllexport) derived_class : public container<conversion_target_movable>
> {
> ...
> };

This code actually really triggers the mentioned compile error. Standard wording can't help us here, because the standard doesn't say anything about dynamic link libraries. So I wouldn't see this as a bug, even if it is annoying at times.

Regards,
Thomas