Re: Bad use of stringstream temporary?
Hi Victor!
And thank you.
On Mar 24, 4:28 pm, Victor Bazarov <v.baza...@comcast.invalid> wrote:
On 3/24/2011 4:18 PM, K. Frank wrote:
...
Victor Bazarov wrote:
On 3/24/2011 12:08 PM, K. Frank wrote:
The basic question is whether the following line of code
is legal and good (according to the current standard):
std::string s1 = dynamic_cast<std::stringstream&>(std::stringstrea=
m() << "abc").str();
...
Note, inserting other stuff in place of std::flush has the same
effect:
...
std::string s = dynamic_cast<std::stringstream&>(std::stringstream() =
<< 123 << "abc").str();
prints out "123abc".
...
I'm not sure exactly how the manipulators are processed, but as I
understand it, when first inserting 123 or "xyz", the member-function
operator<< is called, and then returns (*this). (*this) is still
the unnamed temporary, so the second insertion (<< "abc") should
again resolve to the member-function operator<< for void*, and so
should again print out the pointer value rather than "abc".
No. Unnamed temporary it is, but the call to the first member (to
output the number or the pointer) returns a reference to non-const,
which then is passed directly to the non-member. There is no binding o=
f
a reference to a temporary after the first call.
Example:
struct A {
A& foo();
};
A& bar(A&);
int main() {
A().foo(); // OK
bar(A().foo()); // OK
bar(A()); // not OK - attempt to bind a non-const ref to =
a temp
}
It's as if the first insertion operator causes the fact that we're
processing an unnamed temporary to be forgotten, and the second
insertion now resolves (incorrectly?) to the free-function operator<<
for char*, and prints out "abc" rather than the pointer value.
No. The temporary is an object. It's temporary, but not constant. =
The
language rules require that when a reference is initialized from a
temporary, the reference has to be to a const object. But since the
temporary object is non-const, a non-const member function is allowed to
be called for it. That function can return a reference to non-const,
and you can initialize another non-const ref with that ref, and so on,
and use the object (and change it) *as long as* the temporary is still
*alive*.
Is this now a compiler error, or is there another layer of explanation
that makes this the correct behavior?
That's correct behaviour. You can call it a loophole in the language.
Thank you, Victor, for the clear explanation.
(I will admit that I've now taken a stroll through some alleys and
byways
I hadn't intended to tour.)
I have set myself a homework problem:
<< loophole.cpp >>
#include <iostream>
struct Loophole {
Loophole (int i) : i_(i) {}
Loophole &loophole() { return *this; }
int i_;
};
void print_incr_i (Loophole &l) {
l.i_++;
std::cout << "l.i_ = " << l.i_ << std::endl;
}
int main (int argc, char *argv[]) {
print_incr_i (Loophole (99).loophole());
// next line gives: error: invalid initialization of non-const
reference
print_incr_i (Loophole (66));
}
Does this correctly illustrate your explanation? As it stands, the
program fails to compile, with the error indicated in the comment.
But after commenting out the second call to print_incr_i, the program
compiles and prints out 100, as I would expect.
Even though legal, is this code "bad"? It does seem like I'm
sneaking around a restriction that the language purposely imposes.
And if this is bad, is using the temporary stringstream (with the
"<< std::flush" hack) also bad for the same reason?
V
Thanks again.
K. Frank