Timing of Destruction of Temporary Objects
Nathan Phillips
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
> 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
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!
Victor Bazarov
> 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);
Hopefully this is inside a function...
> What I am getting at is, is it possible that the memory referred to by j is
> deallocated before foo is called?
The destruction of the C temporary should happen at the semicolon (after
the evaluation of the full expression), IOW, after 'foo' returns. So,
to answer you last question, yes, it's possible, but only with a really
badly non-conforming compiler.
> 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.
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'.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jeff Schwab
> In the following code at what point is the temporary object of class C
> destroyed?
>
> class C
> {
> public:
> int i;
> }
>
> void foo(int & j);
Assuming you've snipped some code here...
> foo(C().i);
The temporary is destroyed at the end of the statement.
> What I am getting at is, is it possible that the memory referred to by j is
> deallocated before foo is called?
No, not in standard C++.
> References would be appreciated if possible!
See section 12.2, paragraph 5, of the current standard: "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."
> 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.
Fear not. :)
Nathan Phillips
>* 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?
>
>> 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.
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
news:gpb862$9d0$1...@news.datemas.de...
> Nathan Phillips wrote:
>> 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.
>
> 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)
Victor Bazarov
> [..] 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);
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.
Victor Bazarov
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.
Chetan
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.