Exercise code/operators, about the solution

[chavid]

@sponce @bernhardmgruber @hageboeck I generally recommand to make any unary constructor explicitly. Yet, in this example, how dangerous is it to let the compiler transform an int into some Fraction ? If you allow this, the implementation of operators is made largely simpler.

[bernhardmgruber]

I would still advice against making the unary constructor explicit, since we want to also set good examples.

Apart from that, looking at the solution to the operators exercise, where do you think an implicit conversion from int to Fraction would help?

[chavid]

If you allow the implicit conversion, for each operator, on eonly need to implement the version (Fraction const &, Fraction const &), and there is no need to implement (Fraction const &, int) and (int, Fraction const &).

[bernhardmgruber]

If you allow the implicit conversion, for each operator, on eonly need to implement the version (Fraction const &, Fraction const &), and there is no need to implement (Fraction const &, int) and (int, Fraction const &).

Hmm. I see. That would save you 5 operators, indeed. However, it might be less efficient since you now perform extra work in operator+= and operator*=. But apart from that, I think nothing forbids you from making your constructor non-explicit. It is a valid solution and will pass the tests in main.

[chavid]

Also, if performance is the aim, I feel that implementing >= <= > reusing > and == is not always optimal ;) To be checked, I did not dig this. And I rather prefer the spirit of the exercise the way it is currently, promoting "consistency first", which you ensure implementing >= <= > from > and ==.

[stale]

This issue or pull request has been automatically marked as stale because it has not had recent activity. Please manually close it, if it is no longer relevant, or ask for help or support to help getting it unstuck. Let me bring this to the attention of @klieret @wdconinc @michmx for now.