473,387 Members | 1,532 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,387 software developers and data experts.

Temporary King

Hi,

I would like to double check how long a temporary returned by a function
lives?

Suppose I have an instance of a class type C, which has a member function
returning some sort of wrapper-decorator by value - thereby creating an
unnamed temporary. Assuming I start using the temporary (by calling its
members) in the same expression, can I assume that it will live long enough
to serve those calls?

So assume that o.wrapper() returns a wrapper type T by value. The foo() and
bar() are member functions of that unnamed temporary of type T, where both
(at least foo) return a reference to T. The full expression is:

o.wrapper().foo().bar();

Of course it could be continued ad nauseam. I am 99% sure that the
temporary should live long enough, but... not 101%. :-) Could someone help
me out with the right answer... and - if possible - the chapter and verse?

TIA

--
WW aka Attila
:::
We don't stop playing because we grow old, we grow old because we stop
playing.
Jul 23 '05 #1
5 1668

White Wolf wrote:
Hi,

I would like to double check how long a temporary returned by a function lives?

Suppose I have an instance of a class type C, which has a member function returning some sort of wrapper-decorator by value - thereby creating an unnamed temporary. Assuming I start using the temporary (by calling its members) in the same expression, can I assume that it will live long enough to serve those calls?

So assume that o.wrapper() returns a wrapper type T by value. The foo() and bar() are member functions of that unnamed temporary of type T, where both (at least foo) return a reference to T. The full expression is:

o.wrapper().foo().bar();

Of course it could be continued ad nauseam. I am 99% sure that the
temporary should live long enough, but... not 101%. :-) Could someone help me out with the right answer... and - if possible - the chapter and verse?
TIA

--
WW aka Attila
:::
We don't stop playing because we grow old, we grow old because we stop playing.


Temporaries are valid until the full expression has been completed. So
your code is perfectly safe.

-shez-

Jul 23 '05 #2
shez wrote:
White Wolf wrote:

[SNIP]
o.wrapper().foo().bar();

Of course it could be continued ad nauseam. I am 99% sure that the
temporary should live long enough, but... not 101%. :-) Could someone
help me out with the right answer... and - if possible - the chapter
and verse?


Temporaries are valid until the full expression has been completed. So
your code is perfectly safe.


That is what I know, but I was hoping for chapter and verse to support that
claim.

--
WW aka Attila
:::
'The common people like to be deceived. Deceived let them be' --Old Roman
Saying
Jul 23 '05 #3
White Wolf wrote:


So assume that o.wrapper() returns a wrapper type T by value. The foo() and
bar() are member functions of that unnamed temporary of type T, where both
(at least foo) return a reference to T. The full expression is:

o.wrapper().foo().bar();

Of course it could be continued ad nauseam. I am 99% sure that the
temporary should live long enough, but... not 101%. :-)
100% is enough. You are right
Could someone help
me out with the right answer... and - if possible - the chapter and verse?


Sure.

12.2 Temporary objects

3 .... Temporary objcets are destroyed as the last step in evaluating the full
expression (1.9) that (lexically) contains the point where they were created.
This is true even if that evaluation ends in throwing an exception.

4 There are two contexts in which temporaries are destroyed at a different point
then the end of the fill expression. The first context is when an expression
appears as an initializer for a declarator defining an object. In that context,
the temporary that holds the result of the expression shall persist until the
object's initialization is complete. The object is initialized from a copy of
the temporary; during this copying, an implementation can call the copy constructor
many times; the temporary is destroyed after it has been copied, before or when
the initialization completes. ....

5 The second context is when a reference is bound to a temporary. The temporary to which
the reference is bound or the temporary that is the complete object to a subobject
of which the temporary is bound persists for the lifetime of the reference except
as specified below. ....
( Lots more dealing with exceptions of the above. Basically those exceptions deal
with temporaries bound to a reference in an initializer list, temporaries created
for function argument passing, return values )

--
Karl Heinz Buchegger
kb******@gascad.at
Jul 23 '05 #4
Karl Heinz Buchegger wrote:
White Wolf wrote:


So assume that o.wrapper() returns a wrapper type T by value. The
foo() and bar() are member functions of that unnamed temporary of type
T, where both (at least foo) return a reference to T. The full
expression is:

o.wrapper().foo().bar();

Of course it could be continued ad nauseam. I am 99% sure that the
temporary should live long enough, but... not 101%. :-)


100% is enough. You are right
Could someone help
me out with the right answer... and - if possible - the chapter and
verse?


Sure.

12.2 Temporary objects

3 .... Temporary objcets are destroyed as the last step in evaluating
the full expression (1.9) that (lexically) contains the point where
they were created. This is true even if that evaluation ends in
throwing an exception.

4 There are two contexts in which temporaries are destroyed at a
different point then the end of the fill expression. The first context
is when an expression appears as an initializer for a declarator
defining an object. In that context, the temporary that holds the
result of the expression shall persist until the object's
initialization is complete. The object is initialized from a copy of
the temporary; during this copying, an implementation can call the
copy constructor many times; the temporary is destroyed after it has
been copied, before or when the initialization completes. ....

5 The second context is when a reference is bound to a temporary. The
temporary to which the reference is bound or the temporary that is the
complete object to a subobject of which the temporary is bound
persists for the lifetime of the reference except as specified below.
.... ( Lots more dealing with exceptions of the above. Basically those
exceptions deal with temporaries bound to a reference in an
initializer list, temporaries created for function argument passing,
return values )


Thanks Karl! I am always afraid to look for new stuff in the standard, as I
have managed to get lost many times. But sometimes (shame on me) the answer
is simply in a section with the right title. Oh my. Thanks again.

So I guess that also means that my call-chain does count as one expression,
and no exceptional rules (or exceptions to the rules) allow that temporary
to disappear.

--
WW aka Attila
:::
If you think education is expensive, try ignorance.
Jul 23 '05 #5
"White Wolf" <wo***@freemail.hu> wrote in message
news:ct**********@phys-news1.kolumbus.fi...
shez wrote:
White Wolf wrote: [SNIP]
o.wrapper().foo().bar();

Of course it could be continued ad nauseam. I am 99% sure that the
temporary should live long enough, but... not 101%. :-) Could someone
help me out with the right answer... and - if possible - the chapter
and verse?


Temporaries are valid until the full expression has been completed. So
your code is perfectly safe.


That is what I know, but I was hoping for chapter and verse to support

that claim.


You asked for it! :-)

================================================== ====================
ISO/IEC 14882:1998(E)

12.2 Temporary objects

1 Temporaries of class type are created in various contexts:
binding an rvalue to a reference (8.5.3), returning an rvalue
(6.6.3), a conversion that creates an rvalue (4.1, 5.2.9,
5.2.11, 5.4), throwing an exception (15.1), entering a handler
(15.3), and in some initializations (8.5). [Note: the lifetime
of exception objects is described in 15.1. ] Even when the
creation of the temporary object is avoided (12.8), all the
semantic restrictions must be respected as if the temporary
object was created. [Example: even if the copy constructor is
not called, all the semantic restrictions, such as accessibility
(clause 11), shall be satisfied. ]

2 [Example:

class X {
// ...
public:
// ...
X(int);
X(const X&);
~X();
};

X f(X);

void g()
{
X a(1);
X b = f(X(2));
a = f(a);
}

Here, an implementation might use a temporary in which to
construct X(2) before passing it to f() using X’s copy*
constructor; alternatively, X(2) might be constructed in the
space used to hold the argument. Also, a temporary might be
used to hold the result of f(X(2)) before copying it to b
using X’s copy*constructor; alternatively, f()’s result might
be constructed in b. On the other hand, the expression a=f(a)
requires a temporary for either the argument a or the result
of f(a) to avoid undesired aliasing of a. ]

3 When an implementation introduces a temporary object of a
class that has a non*trivial constructor (12.1), it shall
ensure that a constructor is called for the temporary object.
Similarly, the destructor shall be called for a temporary with
a non*trivial destructor (12.4). Temporary objects are destroyed
as the last step in evaluating the full*expression (1.9) that
(lexically) contains the point where they were created. This is
true even if that evaluation ends in throwing an exception.

4 There are two contexts in which temporaries are destroyed at a
different point than the end of the full*expression. The first
context is when an expression appears as an initializer for a
declarator defining an object. In that context, the temporary
that holds the result of the expression shall persist until the
object’s initialization is complete. The object is initialized
from a copy of the temporary; during this copying, an implementation
can call the copy constructor many times; the temporary is destroyed
after it has been copied, before or when the initialization completes.
If many temporaries are created by the evaluation of the initializer,
the temporaries are destroyed in reverse order of the completion of
their construction.

5 The second context is when a reference is bound to a temporary.
The temporary to which the reference is bound or the temporary
that is the complete object to a subobject of which the temporary
is bound persists for the lifetime of the reference except as
specified below. A temporary bound to a reference member in a
constructor’s ctor*initializer (12.6.2) persists until the con-
structor exits. A temporary bound to a reference parameter in a
function call (5.2.2) persists until the completion of the full
expression containing the call. A temporary bound to the returned
value in a function return statement (6.6.3) persists until the
function exits. In all these cases, the temporaries created during
the evaluation of the expression initializing the reference, except
the temporary to which the reference is bound, are destroyed at the
end of the full*expression in which they are created and in the
reverse order of the completion of their construction. If the life-
time of two or more temporaries to which references are bound ends
at the same point, these temporaries are destroyed at that point in
the reverse order of the completion of their construction. In addition,
the destruction of temporaries bound to references shall take into
account the ordering of destruction of objects with static or automatic
storage duration (3.7.1, 3.7.2); that is, if obj1 is an object with
static or automatic storage duration created before the temporary is
created, the temporary shall be destroyed before obj1 is destroyed; if
obj2 is an object with static or automatic storage duration created
after the temporary is created, the temporary shall be destroyed after
obj2 is destroyed. [Example:

class C {
// ...
public:
C();
C(int);
friend C operator+(const C&, const C&);
~C();
};
C obj1;
const C& cr = C(16)+C(23);
C obj2;

the expression C(16)+C(23) creates three temporaries. A first
temporary T1 to hold the result of the expression C(16), a
second temporary T2 to hold the result of the expression C(23),
and a third temporary T3 to hold the result of the addition of
these two expressions. The temporary T3 is then bound to the
reference cr. It is unspecified whether T1 or T2 is created first.
On an implementation where T1 is created before T2, it is guaranteed
that T2 is destroyed before T1. The temporaries T1 and T2 are bound
to the reference parameters of operator+; these temporaries are
destroyed at the end of the full expression containing the call to
operator+. The temporary T3 bound to the reference cr is destroyed
at the end of cr’s lifetime, that is, at the end of the program.
In addition, the order in which T3 is destroyed takes into account
the destruction order of other objects with static storage duration.
That is, because obj1 is constructed before T3, and T3 is constructed
before obj2, it is guaranteed that obj2 is destroyed before T3, and
that T3 is destroyed before obj1. ]
================================================== ====================
-Mike

Jul 23 '05 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: mosesdinakaran | last post by:
Can any one explain how the rule is applied for the following Regular expression $Str = 'the red king'; $Pattern = '/((red|white) (king|queen))/'; preg_match($Pattern,$Str,$Val); Result:
5
by: Bob Nelson | last post by:
Right next to K&R2 on my bookshelf is _C Programming: A Modern Approach_ by Professor K.N. King. The second edition of this book is now available. See this URL for details: ...
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.