[boost] Re: operators.hpp bugs

From: Philippe Mori (philippe_mori_at_[hidden])
Date: 2005-04-25 17:45:03

> Well, according to my guru, that is not how things are supposed to work.
> See Scott Meyers' "Effective C++" 2nd Edition, page 91. His main point is 
> that user-defined types should behave like the built-in types - meaning 
> that a construct like
> (a * b) = c;
> should be illegal, whether a,b, and c are integers, floats or 
> user-defined. So, for consistency, I think that boost operators should 
> return const objects.

I have the first edition of that book and it does not seems to talk about
returning const objects in that older edition. Item 15 (page 48) says
that operator= returns *this.

Which item # are you referring at page 91? It seems like some
important changes were made between both editions.

> You are right about the complex numbers in the STL. And this, of course, 
> makes programming constructs like
> complex<float> x=((a*b)+=c);
> possible.

> I do not see any realistic uses of the non-const return values from the 
> binary operators in complex.h. Can you give me an example?

Well, I see 4 reasons why in general someone would like to be able to
write complex expressions instead of breaking them into multiple
statements.

The first one would be to avoid declaring the type of intermediate
variables which might not always be evident (and in some situations
one could accidently uses a compatible type that would add an
useless conversion without any warning as it might be the case if
someone write complex<double> instead of complex<float>).

The cause of this reason is the absence of type deduction in C++
(I know about workaround in Boost) and many have suggested
to reuse the auto keyword for that...

The second reason is that in some situation we want only one
statement or expression if possible. This include objects that
are initialized in the initialization-list of a constructor and also
in macros that should behave like a statement.

The third one is backward compatibility (it will surely breaks
someone code) and compatibility with the usual ways of doing
things...

The forth one is that in case of operator=, the return value is
(according to a few sources) a non-const reference... and I
was thinking it was a requirement of STL. If this is the case, it
would means that we would allows

   (a = b).do_something();

but not

   (a + b).do_something();

I think that it is not possible to simulate built-in types at 100% as
probably retuning const objects is more restrictive that what
happens with built-in type and non-const is less restrictive.

> And more importantly, are there boost libraries or client libraries that 
> depend on the non-const-ness of the binary operator results in 
> operators.hpp?

I don't knows and I don't think the change would affect me.

Philippe