Re: [boost] rvalue ref best practices?

Subject: Re: [boost] rvalue ref best practices?
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2012-06-09 18:44:09

On Jun 9, 2012, at 6:03 PM, Howard Hinnant wrote:

> On Jun 9, 2012, at 4:21 PM, Daniel Larimer wrote:
> 
> Generic code that expects traditional copy syntax is going to fail to compile when used with your convention:
> 
> template<class T>
>    T
>    min(initializer_list<T> t);
> 
> ...
> 
> etc.

I suspect that you could create something to wrap the explicit-copy type if you really need to use it in such a case:

template<typename T>
class implicit_copyable {
        
        public:	
        implicit_copyable( T e )
        :val(std::move(e)){}

        implicit_copyable( implicit_copyable&& c )
        :val(std::move(c.val)){}

        implicit_copyable( const implicit_copyable& c )
        :val( copy(c.val) ){}
        
        operator T&(){ return val; }
        operator const T&()const { return val; }

        private:	
        T val;	
}

I suspect that generic algorithms that depend on copy syntax, would not be a good match or even be applicable for types that
are implemented as 'explicit copyable only'.   

In my particular case I am passing 'messages' around and they only ever exist in one place at a time.  I want the compiler to tell me when I try to make a copy.  The effect is the same as using unique_ptr<Message> except that Message has value semantics and there is no 'extra' heap allocation for Message which is essentially a pointer to the real data.  

In theory I could 'copy' the message, but that would have to be a carefully considered decision.

> 
> On Jun 9, 2012, at 4:49 PM, Giovanni Piero Deretta wrote:
> 
>> As per http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/ ,
>> if the function is likely to consume or copy the parameter, the best
>> solution is to pass by value. This means you'll only need to provide a
>> single overload.
> 
> "The best solution" has an implicit "always" in it.  Telling programmers they don't have to think, design or measure is a disservice to our industry.  Pass-by-value is a good tool to have in the toolbox.  It is not always the best solution.  There is no solution that is always best.
> 
> ....
> 
> 
> For me this runs about 19% slower one way than the other.  And I have no idea how portable that result is.  Maybe for your application the 19% speed hit (more or less) is inconsequential.  Maybe for someone else's application a 19% speed hit (more or less) is critical.  <shrug>  We the advise givers have no idea.
> 
> Pass-by-value is a good tool in the toolbox.  It is not free.  There are other good tools in the toolbox too.  None of them are free either.

        Good catch.   Rule #1, always profile.  
        
        I suspect that some guidelines on where to use pass-by-value vs my explicit-copy approach would be helpful.  Obviously there is no 'always', but I hate having to think about it every time, so perhaps some rules of thumb are in order. 

> 
> Howard
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost