No Match For Operator+ ???????

It still allows for implicit conversion such as const char* to std::string.

Quote:

---

Originally Posted by Elysia

It still allows for implicit conversion such as const char* to std::string.

---

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.

Quote:

---

Originally Posted by Elysia

Yes, you're right. Only a non-const reference prohibits that kind of behaviour. Isn't it coming with C++0x, though?

---

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?

Quote:

---

Originally Posted by Elysia

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"

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.)