Re: Temporaries, references, lifetimes and const_cast
johnchx2@yahoo.com wrote:
Victor Bazarov wrote:
Paul Thomas wrote:
This has come up before:
<code>
std::string Func() { return "monkey"; }
int main()
{
const std::string &cstr = Func();
std::string &str = const_cast<std::string &>(cstr);
str = "ape";
}
</code>
and the Jury seems to be out still.
Really? What for? It's allowed. Period.
There's a corner case that could make this undefined. 8.5.3/5
allows the creation of a temporary of type const std::string
in the initialization of cstr. Since the temporary object is
const, modifying it through a non-const reference gives rise
to undefined behavior.
That's an interesting point. It pretty much does mean that the
above code is undefined behavior.
The case involving a non class type is even more interesting,
e.g.:
int const& i = 3 ;
const_cast< int& >( i ) = 4 ;
In this case, a "temporary of type "cv1 T1" [const int] is
created [...]". Except that temporaries are rvalues, and
non-class type rvalues don't have cv-qualifiers.
Finally, of course, note the subtle difference in :
char const* foo() { return "monkey" ; }
// ...
std::string const& s = foo() ;
const_cast< std::string& >( s ) = "ape" ;
In this case, there clearly is undefined behavior, because the
temporary of type "cv1 T1" (i.e. const std::string) must be
created. (Since the types aren't reference compatible, we fall
into the last point in ?8.5.3/5.)
Since the standard is about to revoke the permission to create
a copy in this situation, I'd be surprised if the code above
didn't already work on the vast majority of implementations,
so the point is of limited practical importance.
More than simply revoking the permission to create a copy, I
think this part is being reworked somewhat -- and off hand, I
don't know what the decision will be on the legality of any of
the above.
I might add that today, some compilers, for example, g++, DO
make a copy, in specific cases. Arguably, even, it is required
in some specific cases, for lifetime of temporary issues. Which
means that the current situation is that it is not clearly
defined whether it is undefined or not.
--
James Kanze kanze.james@neuf.fr
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]