Re: [RFA] Algorithms vs operator* and operator==

[Paolo Carlini <pcarlini at suse dot de>]

chris jefferson wrote:

> > *But*, now I remember std::fill and std::fill_n: in order to avoid 
> > expensive
> > copies when _ValueType is "big", we should probably use temporary vars
> > (like __value) *only* when __is_scalar<_ValueType>::_M_type is true...
>
> If we could tell if operator* is returning by value or by reference, 
> would this problem go away? If it is returning by reference, then we 
> simply take that reference and store it. If it returns by value, then 
> if we want to take that value more than once, we may as well copy it 
> into a variable, as surely a dereference and an assignment (possibly 
> with return value optimisation) would be cheaper than 2 dereferences 
> (which both return by value)?

Hi again Chris, and thanks for your interesting explanation of the 
meaning hidden in my "big"! ;)
Seriously, I like and agree with most of it, only I'm not sure whether 
it fully captures the complexity of such situations... For instance, 
perhaps we may want to copy-construct in a local variable (a register, 
actually) a "small" type returned by reference and used many times in 
the algorithm (actually, in fill and fill_n, the __is_scalar machinery 
is used exactly for that purpose: to understand whether we can really 
spare the load from memory, since the value fits in a register). Or, we 
may want to avoid copying a "big" type returned by value, in order to 
spare memory, when the benefit caused by saving the dereferencing time 
itself is relatively small...

> Although at the moment I don't believe it's possible to get the return 
> value of a function ¬_¬ , would it be stunningly hard to add as a g++ 
> extension (and a useful one at that, people always seem to be asking 
> for result_of)?

You mean, for instance, boost::function_traits<F>::result_type doesn't 
work for any arity... Yes, seems very difficult to achieve that without 
compiler support and could be useful!

Paolo.