Re: [boost] Proposed changes to operators.hpp

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-08 13:25:17

----- Original Message -----
From: "Daniel Frey" <d.frey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, July 08, 2002 2:07 PM
Subject: Re: [boost] Proposed changes to operators.hpp

> On Mon, 2002-07-08 at 11:56, David Abrahams wrote:
> >
> > > 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.
>
> Well, I added the option to force the implementation to create the
> documented signature, you just have to set
> BOOST_FORCE_SYMMETRIC_OPERATORS. It would IMO be an unnecessary
> restriction to forbid taking the address.
>
> Currently, I have a 36K patch that should be appliable to the
> boost_1_28_0 directory. It adds the new operator.hpp, regression tests
> and documentation. It only patches the compiler-config for the gcc, as
> it is the only compiler that has the NRVO.

...that you know of?

> I use a positive indicator
> (BOOST_HAS_NRVO) instead of a negative (BOOST_NO_NRVO) for simplicity
> now. Shall I post the patch here, send it to you privately or check it
> in to the files section?

Please post it here so everyone can look, but in a compressed archive so
that the line breaks don't get messed up. First, though, please take one
more look over everything to find any mistakes. I'm sure you didn't make
any ;-), but going back and forth to clear up errors and deficiencies in
submitted patches consumes much bandwidth.

Thanks,
Dave