|
Boost : |
From: Daniel Frey (d.frey_at_[hidden])
Date: 2002-07-08 04:40:54
On Mon, 2002-07-08 at 02:46, David Abrahams wrote:
>
> ----- Original Message -----
> From: "Daniel Frey" <d.frey_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Saturday, July 06, 2002 11:05 AM
> Subject: Re: [boost] Proposed changes to operators.hpp
>
>
> > On Wed, 2002-07-03 at 15:04, David Abrahams wrote:
> > > I've got no problem with accepting this patch, provided:
> > >
> > > 1. It passes all the existing tests, with BOOST_NO_NRVO in both states
> >
> > I have some problems in generating test results. It seems that the code
> > that is contained in the 1.28.0-archive doesn't match the code, that
> > generated the result pages. For me, the gcc 2.95.3 produces different
> > results, e.g. the shared_ptr_assign_fail-test fails to fail and there
> > are various other tests that are not contained in the delivered pages.
> > Besides that, it *seems* to me that the changes I provided didn't break
> > anything, but I'm not 100% sure because of the differences described
> > above. Probably the folks who are used to generate the compiler status
> > pages could check this out? Also, I don't have all compilers, OSes,
> > computers, etc. that are needed to generate all existing tests.
>
> 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. 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.
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 :)
Regards, Daniel
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk