Re: const reference / rvalue reference overloads
On 10/08/2010 03:48 PM, Luc Danton wrote:
On 07/10/2010 19:54, Dragan Milenkovic wrote:
On 10/06/2010 10:35 PM, Bo Persson wrote:
Adam Badura wrote:
[snip]
However, I don't like the idea that the function declaration is tied
so much to the implementation. I'll explain...
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.
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)?
It depends on the constructors of MyUnicodeName. If the type has only
constructors taking std::string const&, then you shouldn't bother to
have your own overloads taking std::string&&. If MyUnicodeName has a
std::string&& overload (which, if you think about it, is unlikely unless
MyUnicodeName has an std::string member), you can either provide the two
usual overloads, or pass by value. The same goes if MyUnicodeName itself
has a by-value constructor.
But my argument is that it shouldn't matter. Representation
and implementation should be independent on the interface.
More argument below...
All in all, since the types of the members are a part of the interface,
This is only in the example given. In a general case, members are more
likely to be private, and about recompilation -- we can use pimple.
Also, "modules" keep being mentioned as a future C++ feature,
and I guess "they" won't like this, too (but I was just being
argumentative, no need to discuss modules now).
How about in this case:
virtual void set_name(??? first_name, ??? last_name) = 0;
[snip]
Of course if you still can't stomach ralue refs you can just ignore them
altogether and still benefit from them.
I can't stomach some of their usage which gains approval from this
and sister groups. In the meantime, I have come up with a solution
to this problem that solves all my issues and actually looks clean
and natural to me. Maybe there is a "prior art" here, but I did
neither find nor search for it.
Note that this is just a proof of concept, and only provides
the wanted functionality, so it's incomplete (among others,
lacking definitions of move/copy semantics; maybe error checks;
const_cast also feels a bit ugly although it's correct).
Also, I'm not sure it's a complete solution or does it
have shortcomings. Oh, it's not meant for non-const lvalue
reference parameters.
If I may...
template <typename T>
class param_wrapper {
const T * ptr;
bool is_lvalue;
public:
param_wrapper(const T & t) : ptr(&t), is_lvalue(true) {}
param_wrapper(T && t) : ptr(&t), is_lvalue(true) {}
T move() const {
if (is_lvalue) return *ptr;
else return std::move(const_cast<T &>(*ptr));
}
T copy() const {
return *ptr;
}
};
Person(
param_wrapper<std::string> first_name,
param_wrapper<std::string> last_name
) : m_first_name(first_name.move()), m_last_name(last_name.move()) {}
.... Person ctor will now both do the right thing (tested on GCC
and it had the same number of copies/moves as other solutions),
and it also look good to me. It also handles the "virtual"
case I mentioned above.
--
Dragan
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]