Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at