On Nov 19, 1:29 pm, coder <plcoderREMOVET...@gmail.comwrote:
On Nov 19, 4:13 pm, Johannes Bauer <dfnsonfsdu...@gmx.dewrote:
Marco Manfredini schrieb:
Johannes Bauer wrote:
>So it is clear to me that when using number 3, the
>compiler throws an error - since the created string
>object goes out of scope (and lifespan) immediately after
>the constructor of "a" is called.
No, the compiler throws an error because you are trying to
bind a const reference to a non-const reference. This is
completely unrelated to the lifetime issue.
Oh, okay. Coming from C, I'm not used to a compiler being so
strict on the "const" keyword, but I like it.
The same rules apply in C (except, of course, that C doesn't
have references). You can't assign a pointer to const to a
pointer to non-const in C.
Of course, that wasn't the problem in your original code.
>This seems intriguing. The string is already destroyed,
>however a may keep a reference (moo) to it? How is that
>possible?
References do not protect the referenced object from
destruction - if an objects dies before the reference to
it vanishes, you end up with a "dangling reference". In
that respect, a reference isn't much better that a
pointer.
Okay, that sounds a little bit dangerous - as I thought C++
should guarantee references are always valid (or at least
always not-NULL). Would at least valgrind detect access to
a dangling reference?
Probably, at least if you tried to use it.
Btw. as a certain optimization and a feature to dumbfound
beginners and intermediate users, the following code:
const string &x="Hallo";
cout << x;
Although I don't consider myself to be a greenhorn, this
still dumbfounds me. The assignment operator is overloaded
for const char* to invoke the constructor of std::string,
meaning
There's no assignment operator involved in the above. There is
an implicit conversion of the char const[6] to an std::string.
const string &x = std::string("Hallo");
So - tell me, why doesn't the lifespan of the *actual*
string end in that same line, leaving x to be a dangling
reference?
Because the standard says that it doesn't.
I'm not entirely sure, but according to Stroustrup: "A
temporary created to hold a reference initializer persists
until the end of its reference's scope" (The C++ Programming
Language, Pg 98). This is why the lifespan doesn't end on the
same line.
As for the first case, I'm not so sure, but I'll try to guess.
You were passing a temporary object to another function which
was receiving it in a reference parameter. Because the
reference was not visible in the original scope of the
temporary, the temporary object ceased to exist at the end of
the expression.
In the original code, there were two references: the argument to
the constructor, and the reference in the class. The first was
initialized by the temporary; if it had had a longer lifetime,
then the temporary's lifetime would have been extended. The
second was initialized by another reference, and so can have no
influence on any temporary, anywhere.
Another way of looking at it is to say that the extension of
lifetime is not transitive.
I might add, however, that reference members are a special case
anywhere, and have rules of their own when initialized with a
temporary. The simple rule is: don't.
--
James Kanze (GABI Software) email:ja*********@gmail.com
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