Re: VC BUG,SO BIG
"Igor Tandetnik" wrote:
It should be noted that your program exhibits undefined
behavior. It binds c_ reference to a temporary that is
destroyed at the end of a's constructor. You then call a
method on a dangling reference. From C++ standard:
12.2/5 ... A temporary bound to a reference member in a
constructor's ctor-initializer (12.6.2) persists until the
constructor exits...
"Alexander Grigoriev" wrote:
Note that c(1) temporary should be destroyed when the
constructor ends (12.2.5: A temporary bound to a reference
member in a
constructor's ctorinitializer (12.6.2) persists until the
constructor exits). Calling foo() on it brings undefined
result.
Igor, Alexander,
Do you have any plausible explanation why such exception was
made for constructor-initializer list? As I see it this
shouldn't be too difficult for compiler to hold temporary
object for lifetime of reference member. Something like
that:
struct X
{
const Y& m_y;
X() : m_y(Y(42)) {}
};
// in pseudocode:
struct X
{
const Y& m_y;
bool __m_y_istemp;
X::X()
{
m_y = someY;
__m_y_istemp = __istemp(someY);
}
X::~X()
{
if(__m_y_istemp)
m_y.~Y();
}
};
The disadvantages of above sample are:
1. Additional boolean member per member reference.
2. Non-trivial destructor. However, if Y's destructor is
trivial, then compiler could optimize away both
`X::__m_y_istemp' and `X::~X()', so no impact would be made
on X at all.
Thanks in advance
Alex