It still allows for implicit conversion such as const char* to std::string.
It still allows for implicit conversion such as const char* to std::string.
Originally Posted by Adak
I'm not sure what you mean. The reference has nothing to do with that. This works fine:
Code:void do_something(std::string x) { } int main() { do_something("foo"); }
>> It still allows for implicit conversion such as const char* to std::string.
Perhaps you're thinking of how only some compilers allow conversion to non-const references (because you're binding a temporary to the non-const reference)?
Yes, you're right. Only a non-const reference prohibits that kind of behaviour. Isn't it coming with C++0x, though?
I always tend to pass via const reference unless it's a built-in type to ensure implicit construction and avoiding expensive copying.
I'm not sure. The idea of a non-const reference binding to a temporary is inherently horrifying to me.
Because of potential problems of modifying a temp object?
There's no conceptual problem with modifying a temporary, it's just pointless because... it's temporary.
EDIT: Allowing a non-const reference to bind could also get in the way of a whole slew of possible optimizations.
EDIT EDIT: Look up the "forwarding problem"
Last edited by brewbuck; 05-14-2008 at 10:35 AM.
Note that at least one major compiler (I think gcc) allows this already.
I know VS supports binding non-const default arguments to a reference.
What's coming in C++0x is rvalue references, a new type of reference (the current one will be renamed lvalue reference) that can bind to temporaries, and that actually needs special measures to bind to non-temporaries.
Because of this, you can then rely on the idea that nobody cares what happens to the referenced object. You can steal its state. That's the main idea behind move semantics. (A sane version of what auto_ptr's special copy constructor does.)
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
