Re: Review: Special functions, Quaternions, Octonions

From: Hubert HOLIN (Hubert.Holin_at_[hidden])
Date: 2001-05-18 15:34:02

Paris (U.E.), le 18/05/2001

--- In boost_at_y..., Gary Powell <Gary.Powell_at_s...> wrote:
> > > I have a tendency to write templated assignment operators as
> > >
> > >   octonion temp(a_affecter);
> > >   using std::swap;
> > >   swap(temp, *this);
> > >   return this;
> > >
> > > which is exception safe, but makes an extra temporary copy.
> > 
> > The other way is exception-safe also. People always mistakenly associate
> > exception-safety with the strong guarantee. In many cases the strong
> > guarantee is neither sufficient nor often even neccessary for writing
> > exception-safe programs. The most we should say about the above method is
> > that it "gives stronger exception-safety guarantees than the other way,
> > assuming swap is non-throwing".
> > 
> > Before suggesting that all assignments should be written that way by
> > default
> > it is worth considering whether the strong guarantee will pay off for the
> > class in question.
> > 
> I'm not suggesting that the specializations for float, double, and long
> double be written this way. The issue is one of user defined types.
> 
> for a given class T, is
> 
>   T x, y;
> 
>   x = y; exception safe?
> 
> if a class F has one data member of type T, then
> 
>   F<T> &operator=(F<T> const &rhs)
>  {
>    d = rhs.d;
>    return *this;
>  }
> 
> has the strong guarantee.
> 
>  for two or more data members,
>   F<T> &operator=(F<T> const &rhs)
>  {
>    d1 = rhs.d1;		   
> 	d2 = rhs.d2;	// throws
>    
>    return *this;
>  }
> 
> leaves the class in an incomplete copied state. IMO that's unacceptable for
> the general case.
> 
> But I'm willing to be called confused. And the point is well taken.
> 
> How about a comment in the docs to the effect that assignment does not have
> the strong exception guarantee? After all quatarions are used in graphics
> applications and speed is the issue. (In which case the test for self
> assignment should definitely go.)
> 
>   -gary-
> 
> gary.powell_at_s...

        From the provided documentation (octonion member operators, 
Assignment operators):

                "For the unspecialized form, the base type's assignment 
operators must not throw."

        This is also the way things are (implicitely, if not explicitely) 
done with the unspecialized form of the complex template;

        That being said, if stronger garanties are requested, and there is 
no objection (such as loss of performance), I can add them in.

                Hubert Holin
                Hubert.Holin_at_[hidden]