Timing of Destruction of Temporary Objects

N

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
 
A

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
 
N

Nathan Phillips

Victor Bazarov said:
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)
 
C

Chetan

Victor Bazarov said:
Nathan said:
[..] 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.
 
C

Chetan

Victor Bazarov said:
Chetan said:
Victor Bazarov said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top