🚀 go-pugleaf

In article 223@news, peng@dpg.rnb.com (Wei Peng) writes:
>Hi, I'm sure about what the Std says about the lifetime of temp objects (it
>says tmp objects may live longer... or something alike).

The old rule was that a temporary must be destroyed no later than the
end of the block in which it was created. Some compilers destroyed
temps immediately, some delayed until the end of the block.

The draft standard (which is unlikely to change in this regard) says
that a temporary is destroyed at the end of the complete expression
in which it is created. A "complete expression" is an expression
which is not a subexpression of any other expression.

>A sample code. Suppose we have a string object called String, all necessary
>constructors/operators are well defined. Now we have three functions
>
>void doSomething(const char*);
>
>String getString();
>
>const char* getCharStar()
>{
>  return returnString();
>}
>
>Now if we do:
>
>          doSomething(getCharStar());
>
>Obvously this code doesn't work under old C++, where temp objects only
>live within their scope. My impression is that under STD C++ the tmp
>object created by getString() should live long enough so doSomething()
>can safely execute.

Your example has at least one typo, but I'm going to assume that
function getCharStar looks like this:
	return getString();
and that class String has an implicit conversion to const char*. (The
standard string class does not have that implicit conversion.)

If my assumptions are correct, getCharStar won't work. The return
statement is interpreted as
	return getString().operator const char*();

getString returns a temporary String, and the type-conversion member
function is called. At the end of the return statement, the temp String
is destroyed (under both old and new rules), and you are left with a
dangling pointer, which is then returned to the caller.

Assuming the existence of a strdup function, you would have to write
something like
	return strdup(getString().operator const char*());
so that the returned pointer continues to point to a live object.
---
Steve Clamage, stephen.clamage@eng.sun.com




[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]