Re: const reference / rvalue reference overloads
Dragan Milenkovic wrote:
On 10/06/2010 10:35 PM, Bo Persson wrote:
Person(
std::string first_name,
std::string last_name
)
: m_first_name( std::move( first_name ) ),
m_last_name( std::move( last_name ) )
{ }
This will do the best possible job concerning move and copy. But...
What happens if you decide not to simply copy/move both strings
into the destination member variables, but to use them in
a different manner, for example:
MyUnicodeName m_first_name, m_last_name;
Person(std::string first_name, std::string last_name)
: m_first_name(first_name),
m_last_name(last_name) {}
This will make unnecessary copies if lvalues have been provided
as arguments, and would be much better having been declared as
Person(const std::string &, const std::string &).
Again, I believe that this approach makes interface be dictated
by the implementation, and I don't like it at all! While it is
true that we can change the interface and recompile without
any harm, I feel that this is not a natural way of things.
Oh, I always belived the implementation was dictated by the interface. :-)
Any thoughts? Does this make sense, or is it just my body
trying to reject move semantics (rvalue references have been
poking my liver like forever)?
Your use of move semantics looks like a, possibly premature :-), attempt to
somewhat optimize the implementation. It doesn't change the interface of the
constructor taking two strings.
There are no requirements for you to define move semantics for your classes,
just an additional tool to use whenever it makes sense.
Bo Persson
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]