0

So in this project, I have to create a rationalizer program that helps reduce numbers to a simplified format. The part of the program that I am struggling the most with are the operators with the long parameters.I'm trying to write out the proper conditions so that LongRational will be stored properly into this->_num , this->_den but the logic I've written doesn't seem right. Is there something wrong with my function parameters themself or anyway to correct this.

Rational& Rational::operator += (const Rational& rational)
{
    this->_num += ((rational._num * _den) + (rational._den * _num));
    this->_den += (rational._den * _den);

    return *this;
}

//Part I am having trouble on. Tried editing but unsure if correct.
Rational& Rational::operator += (long LongRational) 
{

    this->_num += (LongRational * _den) + (_num * LongRational);
    this->_den += (LongRational * _num);

    return *this;
}

Rational& Rational::operator -= (const Rational& rational)
{
    this->_num -= ((rational._den * _num) - (_den * rational._num));
    this->_den -= (rational._den * _den);

    return *this;
}

//Part I am having trouble on. Haven't edited this bit yet,
Rational& Rational::operator -= (long LongRational)
{
    this->_num -= LongRational;
    this->_den -= _den;

    return *this;
}

//NOTE: He wants there to be a set of two assignment operators with parameters that takes in a Rational object as it's parameter and another with a long.

  • It looks like if you try to do 5/3 + 2, you end up with 13/5, which is definitely not right. I think you’re mixing up some of your `_num`s and `_den`s. – Daniel H Sep 19 '17 at 21:34
  • 1
    Didn't look at the actual implementation, but you can certainly shorten your code by (1) adding a non-explicit constructor from `long` and killing all the overloads taking `long`, (2) creating a unary minus operator and implementing the `-=` in terms of `+=` and unary minus. Also, all those `const Rational&` are just harmful - passing by value is going to be more efficient, and more convenient when implementing the operators. In the end, you'll be able to concentrate on the only non-trivial operator - `operator+=`. – Matteo Italia Sep 19 '17 at 21:34
  • @MatteoItalia I’m not sure I agree about the `const Rational&` parts. There’s no need to ever do a copy, so why not take those by reference? – Daniel H Sep 19 '17 at 21:36
  • 1
    @DanielH: passing by copy for a couple of `long` values is going to be more efficient than the indirection introduced by the reference on any modern platform (on x86_64 they go straight into registers), and avoid aliasing problems (both of performance and of correctness). `const` references are just a necessary evil for heavyweight objects, for lightweights the more you can avoid them the better. – Matteo Italia Sep 19 '17 at 21:38
  • @MatteoItalia Fair enough, if that’s all that’s in the class (which it should be). I would still prefer keeping the `const` part even without the reference, because there should be no reason to modify the RHS, so making the compiler complain if you try is a good idea. – Daniel H Sep 19 '17 at 21:47
  • Think about how you solve this sort of problem on paper. What is `a/b + c/d`? That's what your `operator+=(const Rational &)` should be. What would `a/b + c` be? That would be for `operator+=(long)`. – 1201ProgramAlarm Sep 19 '17 at 23:55

0 Answers0