Quote:Original post by jpetrie

Quote:
The thing is, though, when the Rational class is templated, the compiler can no longer figure out how to convert EITHER argument because it can't figure out what type to make the second operand. If it's defined in the class, it at least knows what type, and if it's a friend, you can do int * Rational again.

Friendship has nothing to do with what you appear to be describing. Either way, this argument isn't really a good counterpoint to Meyers' suggestion.

I'm not trying to counter-point it, which is why it might have seemed weak. I really liked it! It has to be defined in the class so the compiler knows what type to convert the second operand to and it has to be friend so it can convert the first operand to the second's type (because the first operand can never convert if the function is defined in the class and the friend operator makes it so the compiler treats it as if it was not).

And, after looking back at my code, I realized that I could still benefit from putting my operators in the class (friends, of coarse) so the compiler will know what to convert things.

And explicit is not the keyword I need, but I don't feel like explaining better because the point is moot.

Also, implicit type conversions aren't bad as long as you understand them. If you know how it'll make your code act, you can prepare. They wouldn't be in the language if they weren't very helpful.

Quote:Original post by jpetrieFrom what you've said, you're talking about making a member function versus a free function (both of which can be declared in the scope of the class).

The difference between making a free function, and a non-member, friend function.

I guess if this doesn't explain it, I'll give up:
For the the function a * b where a and b are Rational<T>, if it is defined in the class like so: Rational<T>::op*( Rational<T> b ), the compiler knows what T is because it knows the type of the first operand, a, which called the function. If b is not the right type, but easily convertible, it's fine.

A more clear way to write it:
a.operator*( 4.5f ); // 4.5f is a float, but because the constructor accepts one float, it's implicitly converted to a Rational<T>

But, a can never be converted to a Rational if it's not already. The book says that this (the keyword) can never be converted. So 4.5f.operator*( a ) is invalid because it doesn't know how to convert 4.5 to a rational, or the rational to 4.5's type. Defining it outside the class makes it so the first operand CAN be easily converted.

operator*( a, b );

But, the problem is, the compiler can't tell what T is if a and b aren't the same type.

operator*<T>( a, b );

Now if wither a or b are the wrong type, either can be converted--the book called this mixed math--but the whole point of overloading the * operator was to not have to do such clunky, confusing code. Defining it IN the class, but as a FRIEND gives the best of both worlds.

Here's the class he wrote out (minus some self-referencing comments you wouldn't understand without a copy on hand):

template<typename T>class Rational {public:  ...friend const Rational operator*(const Rational& lhs, const Rational& rhs){  return Rational(lhs.numerator() * rhs.numerator(),                         lhs.denominator() * rhs.denominator());  }                                                         };

So now if a (lhs) OR b (rhs) is of type T, an implicit conversion will take care of the complication. The compiler looks in the class for an operator, and it finds this. Otherwise it looks here and the float class and finds nothing. It knows what type T is because it looks in the class.

This solved a conversion problem I had with magnitude( Vector<T>& v, T newMag ) where if the new mag wasn't of type T, it didn't work.