$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Daniel Frey (d.frey_at_[hidden])
Date: 2002-07-10 04:35:37
On Wed, 10 Jul 2002 01:39:10 +0200, David Abrahams wrote:
>> - The patch concentrates on operators.hpp, but there are other
>> candidates for NRVO, e.g. next/prior. I suggest that we check the
>> result for operators.hpp first and add compiler-configs for other
>> compilers that have the NRVO. If this works well for the next release
>> of boost, we can start to apply the NRVO-scheme to other libs. OK?
>
> I will give you CVS access if you want to make these changes, as long as
> you're willing to be responsible for the consequences (testing,
> documentation).
OK for me, as long as you are satisfied with my documentation :)
>> - I also fixed some inconsistencies in the documentation of
>> operators.hpp, but all very basic stuff that shouldn't be
>> controversial.
>
> I didn't notice.
All functions are in fact "friend", but only one operator was documented being
a "friend", which makes no sense. And there was a space somewhere that
shouldn't be there. The requirements for the operators did name T temp(t);
only when the value was copied inside the function, but not when the copy
was made in the parameter list (by-value-parameters), but this doesn't
mean that T temp(t) is not required. This is now more obvious due to the
NRVO-scheme, but it also applies to the old fallback-implementation.
>> - The implementation of other operators use 'x' and 'y' for the
>> parameters, sometimes they are swapped, sometimes not. This seems
>> inconsistent to me. Is there a common scheme I don't see or should we
>> change the code to use lhs/rhs somewhere in the future?
>
> It doesn't matter much to me.
It kept me thinking for a while to find out why it was done this way. But
in the end, there is no reason for this - I'd like to avoid this
situation for others. I'll probably change it if no one objects.
Regards, Daniel