Prev: You can't trust what the debugger tells you the value is
Next: Solid C++ by example
From: itaj sherman on 27 Jun 2010 00:27
I'm not sure what the standard says about a case like this (mainly per
12.2/5):

class B {};
class D1: public B {};
class D2: public B {};

void foo( bool r )
{
B const& a = ( r ? D1() : D2() );
// Does the temporary live here?
}

itaj

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Goran on 28 Jun 2010 05:39
On Jun 27, 5:27 pm, itaj sherman <itajsher...(a)gmail.com> wrote:
> I'm not sure what the standard says about a case like this (mainly per
> 12.2/5):
>
> class B {};
> class D1: public B {};
> class D2: public B {};
>
> void foo( bool r )
> {
> B const& a = ( r ? D1() : D2() );
> // Does the temporary live here?
>
> }

AFAIK, it does. E.g. ScopeGuard of Petru/Alexandrescu uses that
language feature.

Goran.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Johannes Schaub (litb) on 28 Jun 2010 05:39
itaj sherman wrote:

> I'm not sure what the standard says about a case like this (mainly per
> 12.2/5):
>
> class B {};
> class D1: public B {};
> class D2: public B {};
>
> void foo( bool r )
> {
> B const& a = ( r ? D1() : D2() );
> // Does the temporary live here?
> }
>

I'm sorry to annoy you again, but i've just noticed that the issue report
link i gave was discussing the comma operator instead of the conditional
operator (omg, epic fail). It turns out from links in that issue report
that the issue with the conditional operator has been fixed in C++0x by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#446 . It
provides the "direct reference" i talked about.

Looking at it again, i found an interesting similarity with bit-fields: An
object can be a bit-field, but an expression can be a bit-field likewise.
Like, it's said "the result is of that type and value category and it is a
bit-field if ..." at 5.16/4 in the FCD. If it would omit the addendum, the
expression would potentially refer to a bit-field, but won't be a bit-field
itself. This seems to be exactly like the situation with temporaries. The
lifetime-lengthening subsection refers to the expression property, thus it
doesn't care about lvalues that refer to temporaries, because those lvalues
won't have the "temporary" property be true. But now, i'm just more confused
how these things fit together, really :(

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Johannes Schaub (litb) on 28 Jun 2010 05:37
itaj sherman wrote:

> I'm not sure what the standard says about a case like this (mainly per
> 12.2/5):
>
> class B {};
> class D1: public B {};
> class D2: public B {};
>
> void foo( bool r )
> {
> B const& a = ( r ? D1() : D2() );
> // Does the temporary live here?
> }
>

First of all, that code isn't valid. Let's change it to

B const& a = ( r ? B() : D2() );

"Temporary" is a property of objects and strictly according to standards the
lifetime of it should be lengthened. But the aim of the Standard is that
only "direct" references to temporaries are lifetime-extended. What such a
"direct" reference is, however, isn't specified by the Standard as far as i
know.

In your example, even tho the result is an rvalue that definitely refers to
a temporary, that rvalue refers *either* a temporary coming from the left
*or* from the right side. Thus there is no direct reference anymore, in some
sense.

The issue around ?: and temporaries is subject of http://www.open-
std.org/jtc1/sc22/wg21/docs/cwg_active.html#462 . The direction that #462
drives toward is making "temporary" a property of expressions, instead of a
property of objects, without explicitly mentioning it in that issue report.
That issue report is the only place i know that would attribute it to
expressions explicitly. Many places in the Standard already seem to assume
that, while the text in the Standard is clear that it is a property of
objects.

To me it seems the following solves these questions too, with much less
overhead:

- Say that lifetime extension rules only apply to temporaries that haven't
been bound to references or to the implicit object parameter yet.

This is sort of what the RVO rules do, saying that they only apply to
temporaries that haven't yet been bound to references. I suspect here is a
reason they haven't done this way, but i can't think of a reason.

This would allow the above conditional-expression be lifetime extended too.
It still disallows extending lifetime of a "*this" refering to a temporary
object and other such things, which is the aim of the Standard. It would
keep the term "temporary" to strictly name a property of objects.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: restor on 28 Jun 2010 05:52
On 27 June, 17:27, itaj sherman <itajsher...(a)gmail.com> wrote:
> I'm not sure what the standard says about a case like this (mainly per
> 12.2/5):
>
> class B {};
> class D1: public B {};
> class D2: public B {};
>
> void foo( bool r )
> {
> B const& a = ( r ? D1() : D2() );
> // Does the temporary live here?
>
> }


Hi, the temporary in such a case lives as long as the reference does.
Have a look at this article:
http://herbsutter.com/2008/01/01/gotw-88-a-candidate-for-the-most-important-const/

Your example however will not compile, because operator ?: is not that
clever to deduce that you mean the common base type. You have to cast
at least one of the operands explicitly:

B const& a = r ? static_cast<B&>( D1() ): D2();

Regards,
&rzej

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 |  Next  |  Last
Pages: 1 2
Prev: You can't trust what the debugger tells you the value is
Next: Solid C++ by example