Re: [boost] Proposed changes to operators.hpp

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-08 04:56:02

From: "Daniel Frey" <d.frey_at_[hidden]>

> > Sorry, you only have to pass the operators.hpp test suite. In the
status
> > subdirectory:
> >
> >     bjam -sTOOLS=... operators
>
> Again it seems we are talking about different versions, as I don't have
> a test-suite for operators in my Jamfile.

Naw, my mistake:

    bjam -sTOOLS=... operators_test

> Anyway, I added an appropriate
> section and wrote two new tests to check that code like (a+b)=c and
> a++++ fails to compile. I checked these tests (together with
> operators_test.cpp) for GCC 2.95.3, GCC 3.1 and the Intel C++. They
> succeeded with both BOOST_NO_NRVO set and unset. The final patch will
> contain the new tests as well as the modified Jamfile, you'll probably
> have to merge it with your version if there are conflicts. I'll also
> modify all compiler-configs, adding BOOST_NO_NRVO for all compilers
> expect the GCC, which will activate the NRVO for version 3.1+. This is a
> conservative approach, but it is safer than trying to apply the NRVO
> blindly to every compiler. When more people provide some feedback, the
> configs will improve. While we are at it: Greg Comeau should be able to
> provide information about the Comeau... :)
>
> > Pass the tests you can run yourself, make the changes I requested,
submit
> > any needed doc patches.
>
> For the doc, there is a simple problem: The docs say that the Supplied
> Operations looks like this:
>
> T operator+(T, const T&)
>
> changing the return type to const is straight forward, but the
> parameters depend on the compiler (or even worse, the compiler version
> and the user-config). I currently plan to replace the above line with
>
> const T operator+(const T&, const T&)
>
> and add a footnote to all operators that depend on the NRVO-settings.

OK. In the standard we could handle that with the as-if rule and the fact
that the user can't reliably take the address of a library-supplied
function, but your way seems simpler.

> This way anything is kept brief and the user will hopefully don't get
> confused about this too much. The footnote will then explain about the
> NRVO, it's consequences, the BOOST_FORCE_SYMMETRIC_OPERATORS and the
> by-value parameters as an optimization for compilers without NRVO. Is
> this OK or do you have any better idea? (I know I'm not good in writing
> documentation :)

It sounds like you have a good approach.

-Dave