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,
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk