Re: VC BUG,SO BIG

From:

"Alex Blekhman" <xfkt@oohay.moc>

Newsgroups:

microsoft.public.vc.language

Date:

Wed, 20 Sep 2006 13:41:47 +0300

Message-ID:

<up1QhFK3GHA.4228@TK2MSFTNGP06.phx.gbl>

"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