This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFA] Algorithms vs operator* and operator==
Paolo Carlini wrote:
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...
Ah, woops. I made a little mistake :) in the case where the variable is
small then of course even if it is returned by reference then we should
still take a copy of it! Sorry.
In the case of large things however, I was considering that either a) it
is returned by reference (in which case why dereference twice, we can
just capture the reference) or b) it is returned by value, in which case
if we want to use it more than once, we may as well copy it into a
variable, as surely that can't be any more expensive than dereferencing
again and having another return-by-value? (or am I missing something?).
The only case I can see where you would want to dereference more than
once would be where a) the data was returned by reference and b) you
didn't realise that an copied the object (in which case, lets just not
do that).
Chris