Re: reference to non-const temporary
Frederick Gotham wrote:
Ethan Eade posted:
I'm curious -- why aren't temporaries allowed to be passed as non-const
references?
If you pass either:
(1) non-const reference
(2) pointer to non-const
to a function, then that implies that the function is going to alter
something.
Logic dictates that you only alter something if there's a reason to.
If you pass a temporary, then any such alterations will be lost.
But there are times when we don't care.
What useful 'alterations' do you succeed to keep because you can't write
void process(std::istream&);
process(std::ifstream(filename));
but instead you have to write
void process(std::istream&);
std::ifstream tmp(filename);
process(tmp);
? Because you can't write
bool extract(std::istream& is, int& i) { return is >> i; }
std::string s("123"); int i;
extract(std::istringstream(s), i);
but instead you have to write
bool extract(std::istream& is, int& i) { return is >> i; }
std::string s("123"); int i;
std::istringstream is(s);
extract(is, i);
// "is" not needed any more
? (The gain is a pain in the neck, I think.)
Why does the language offer us "a nice safety feature" that we always
have to accept even though we may not want? Why does it force us to
resort to hacks such as "ostringstream().flush() << ..." instead of
plain, simple, and intuitive "ostringstream() << ..."?
As I have written several times in newsgroups, it does makes sense to
forbid bounding to a non-const reference a temporary created through
implicit conversion (as in
void incr(int& r) { r++; }
double d = 1;
incr(d);
), but not to forbid it for all temporaries, in particular explicitly
created ones such as foo().
Is anything going on to change this?
It seems slightly arbitrary, since non-const methods can be
called on them anyway.
But it still ensures that we don't discard alterations.
How?
struct foo { int x; void f() { ++x; } };
foo().f();
How does the language help you not to discard alterations on the
temporary foo()?
Surely such temporaries are fully constructed
objects. What's the rationale? It seems the restriction is trivially
circumvented using operator=():
struct Foo {};
Foo make() { return Foo(); }
void use(Foo& foo) { }
int main()
{
use(make()); // Fails, as discussed above
use(Foo() = make()); // Compiles
}
This I just plain don't understand. In the last line in "main", it appears
you're assigning to an R-value.
Since when can we assign to an R-value?
A long time ago, though I cannot tell exactly.
Furthermore, since when can this R-value then be passed by non-const
reference... ?
The return value of the assignment operator is an lvalue.
--
Seungbeom Kim
---
[ 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 ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]