Timing of Destruction of Temporary Objects

[Nathan Phillips]

In the following code at what point is the temporary object of class C
destroyed?

class C
{
public:
int i;
}

void foo(int & j);

foo(C().i);

What I am getting at is, is it possible that the memory referred to by j is
deallocated before foo is called?

I'm not so interested in what particular compilers do, though if you happen
to know for DJGPP then that would be useful, but whether the C++ standards
specify the behavior here. References would be appreciated if possible!

If you're interested, the particular code that raises this issue is where
class C is a smart pointer class returned by another function called within
the argument list of a function. i.e. foo(arg1, *getSmartPtr(), arg3). My
fear is that the destructor for the object pointed to may be called before
it is passed into foo.

Thanks in advance for any useful comments, Nathan

 

[Alf P. Steinbach]

* Nathan Phillips:

In the following code at what point is the temporary object of class C
destroyed?

class C
{
public:
int i;
}

void foo(int & j);

foo(C().i);

What I am getting at is, is it possible that the memory referred to by j is
deallocated before foo is called?
No.


I'm not so interested in what particular compilers do, though if you happen
to know for DJGPP then that would be useful, but whether the C++ standards
specify the behavior here. References would be appreciated if possible!

Temporary lasts to the end of the full-expression.

Search for relevant words in that sentence.

If you're interested, the particular code that raises this issue is where
class C is a smart pointer class returned by another function called within
the argument list of a function. i.e. foo(arg1, *getSmartPtr(), arg3). My
fear is that the destructor for the object pointed to may be called before
it is passed into foo.

Nope.


Cheers & hth.,

- Alf

 

[Nathan Phillips]

* Nathan Phillips:


Temporary lasts to the end of the full-expression.

Brilliant, thank you, that's what I hoped. The following site confirms this
in some detail. Thanks again for the pointer!

http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=198

Cheers, Nathan

 

[Nathan Phillips]

That should not happen, at least not according to the Standard. Beware,
though, of returning an automatic object from a function. In certain
conditions the object doesn't survive the return, and the smart pointer
your 'getSmartPtr' returns wraps an invalid pointer (the address of an
object that has been destroyed upon 'getSmartPtr's exit).

So, it's likely *not* the 'foo' or the compiler, but 'getSmartPtr'.

Are you warning against returning a pointer to a variable from the scope of
getSmartPtr? If so then thanks, if not then I don't understand your comment,
especially the phrase "certain conditions" confused me. Are you saying there
could be a problem with the following code, assuming that Ptr is a class
that does reference counting for a dynamically allocated object?

Ptr<C> getSmartPtr()
{
return Ptr<C>(new C());
}
foo(arg1, *getSmartPtr(), arg3);

Nathan (amazed by the speed of responses here)

 

[Chetan]

[..] Are you saying there
could be a problem with the following code, assuming that Ptr is a class that
does reference counting for a dynamically allocated object?

Ptr<C> getSmartPtr()
{
return Ptr<C>(new C());
}
foo(arg1, *getSmartPtr(), arg3);

No, since your C object is 'new'ed, there should be no problem (unless there is
something funky with the implementation of 'Ptr' itself. I was mostly worried
about something like

C c;
...
return Ptr<C>(&c);

V

However, to note, it isn't a temporary the way it is, so it
isn't getting destroyed at all.

 

[Chetan]

Nathan Phillips wrote:
[..] Are you saying there
could be a problem with the following code, assuming that Ptr is a class that
does reference counting for a dynamically allocated object?

Ptr<C> getSmartPtr()
{
return Ptr<C>(new C());
}
foo(arg1, *getSmartPtr(), arg3);
No, since your C object is 'new'ed, there should be no problem (unless there is
something funky with the implementation of 'Ptr' itself. I was mostly worried
about something like

C c;
...
return Ptr<C>(&c);

V

However, to note, it isn't a temporary the way it is, so it
isn't getting destroyed at all.

What isn't a temporary? The smart pointer itself *is* when it is returned /by
value/. The whole point of the temporary smart pointer is that when it isn't
needed any more, the last one of them (in the chain of ownership transfers from
a temporary to a temporary) will destruct the owned object.

V

What I was referring to was that it is always a bad choice to be returning
pointers to automatic objects from functions, whether using smart
pointer or not.