On 6 May 2014 15:55, Rob Stewart wrote:

On May 6, 2014 9:37:33 AM EDT, Jonathan Wakely wrote:

...

On 6 May 2014 12:45, Andrzej Krzemienski wrote:

...

Do you know if this a bug in VC++, or if that is supposed to be

valid?

It's valid, the reference should bind directly to global_i.

In the code he provided, the assertion failure means that the address of the reference ii != the address of global_i. That's surprising.

Maybe I misunderstood the exact question. Obviously it's surprising, because it's wrong, like I said "the reference should bind directly to global_i" i.e. it should not bind to a temporary. What I meant (but might have failed to say) is that the program is valid, and the assertion should not fail. I didn't mean VC++'s behaviour is valid.

On Fri, May 30, 2014 at 11:17 AM, Andrzej Krzemienski wrote:

2014-05-06 17:06 GMT+02:00 Jonathan Wakely :

...

I didn't mean VC++'s behaviour is valid.

Would that qualify for a C++03 defect macro in Boost.Config?

Yes, if several Boost libraries are likely to need to detect this problem. OTOH, Boost.Config doesn't supply defect macros for all compiler bugs, so if is unlikely multiple libraries need such a macro then it doesn't have a place in Boost.Config. HTH, --Beman

On 6 May 2014 17:35, Philippe Vaucher wrote:

...

Do you know if this a bug in VC++, or if that is supposed to be valid?

Can you print the values of &ii and &global_i before the assert? I don't quite see what `ii` could bind to...

It's probably creating a copy-initialized temporary and binding to that temporary.

[Andrzej Krzemienski]

the following program fires an assert in MS VC++ compiler (v. 10.0, 11.0, 12.0):

[Jonathan Wakely]

It's probably creating a copy-initialized temporary and binding to that temporary.

[STL]

Still repros with our current development build. I've filed this as DevDiv#939829 "operator=(const int& ii) creates a temporary when it shouldn't" in our internal database.

The compiler team has fixed this in the next major version of VC. Thanks, STL