Is this a MSVC bug?
Hi, While tracking test failures in Boost.Optional library I discovered that the following program fires an assert in MS VC++ compiler (v. 10.0, 11.0, 12.0): #include <cassert> const int global_i = 0; struct TestingReferenceBinding { void operator=(const int& ii) { assert(&ii == &global_i); } void operator=(int&&) { } }; int main() { TestingReferenceBinding ttt; ttt = global_i; } Do you know if this a bug in VC++, or if that is supposed to be valid? Regards, &rzej
On May 6, 2014 9:37:33 AM EDT, Jonathan Wakely <jwakely.boost@kayari.org> 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. ___ Rob (Sent from my portable computation engine)
On 6 May 2014 15:55, Rob Stewart <robertstewart@comcast.net> wrote:
On May 6, 2014 9:37:33 AM EDT, Jonathan Wakely <jwakely.boost@kayari.org> 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.
2014-05-06 17:06 GMT+02:00 Jonathan Wakely <jwakely.boost@kayari.org>:
On May 6, 2014 9:37:33 AM EDT, Jonathan Wakely <jwakely.boost@kayari.org> 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
On 6 May 2014 15:55, Rob Stewart <robertstewart@comcast.net> wrote: 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.
Would that qualify for a C++03 defect macro in Boost.Config?
On Fri, May 30, 2014 at 11:17 AM, Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
2014-05-06 17:06 GMT+02:00 Jonathan Wakely <jwakely.boost@kayari.org>:
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.
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. Thanks, STL
[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
On Tue, May 6, 2014 at 4:45 AM, Andrzej Krzemienski <akrzemi1@gmail.com>wrote:
Hi, While tracking test failures in Boost.Optional library I discovered that the following program fires an assert in MS VC++ compiler (v. 10.0, 11.0, 12.0):
#include <cassert>
const int global_i = 0;
struct TestingReferenceBinding { void operator=(const int& ii) { assert(&ii == &global_i); }
void operator=(int&&) { } };
int main() { TestingReferenceBinding ttt; ttt = global_i; }
Do you know if this a bug in VC++, or if that is supposed to be valid?
I think MSVC is at fault. I'm curious -- what if you explicitly declare it static? What if you make it extern and const but define it in the same translation unit? What if you use a const type that isn't integral (I.E. a float)? IIRC, I think this type of behavior is allowed with static const integral data-members when initialized inline, but is illegal for non-member consts, though I don't have the standard in front of me. It sounds like they might just be treating static global integral constants the same way. -- -Matt Calabrese
participants (7)
-
Andrzej Krzemienski -
Beman Dawes -
Jonathan Wakely -
Matt Calabrese -
Philippe Vaucher -
Rob Stewart -
Stephan T. Lavavej