It still allows for implicit conversion such as const char* to std::string.
This is a discussion on No Match For Operator+ ??????? within the C++ Programming forums, part of the General Programming Boards category; 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.
For information on how to enable C++11 on your compiler, look here.
よく聞くがいい!私は天才だからね! ^_^
>> 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.
For information on how to enable C++11 on your compiler, look here.
よく聞くがいい!私は天才だからね! ^_^
Because of potential problems of modifying a temp object?
For information on how to enable C++11 on your compiler, look here.
よく聞くがいい!私は天才だからね! ^_^
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.
For information on how to enable C++11 on your compiler, look here.
よく聞くがいい!私は天才だからね! ^_^
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