Re: Checking exception specifications

["Ross Smith" <ross dot s at ihug dot co dot nz>]

From: Sebastian Ritterbusch <uabp@rz.uni-karlsruhe.de>
>
>#include <iostream>
>class complex
>{
>   private:    double re,im;
>      friend double & Real(complex &a) { return a.re; }
>      friend double & Imag(complex &a) { return a.im; }
>};
>std::ostream & operator <<(std::ostream &o,const complex &a)
>{  // Or another "User"-written function
>   return o << Real(a) << '+' << Imag(a) << 'i';
>   // If the compiler isn't _very_ smart ;), this will result
>   // in a warning although a isn't changed.
>}
>
>Okay, there are several ways to get around this but in my opinion
>is warning about "const" the same thing as warning about possibly
>unhandled exceptions. If you are serious about exceptions you will
>agree.

No. The above is very bad code, and any competent compiler will give a
fatal error for attempting to use non-const methods of a const object. I
can't understand why you'd write private methods like that in the first
place (in a friend context, with access to the objects private members,
why not just use the data members directly?), but if you write non-const
accessors, you should accompany them with const equivalents.

I don't see any analogy with exceptions. Potentially unhandled
exceptions may or may not be valid; as I and the original poster pointed
out, there are too many cases where a compiler can't do the necessary
analysis and would give a false warning. Const incorrectness is always
unambiguous, and should always be a fatal error.

--
Ross Smith ................................... mailto:ross.s@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
  "Remember when we told you there was no future? Well, this is it."
                                                        -- Blank Reg