Closed
Description
@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.
Activity
bernhardmgruber commentedon Oct 6, 2022
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
toFraction
would help?chavid commentedon Oct 6, 2022
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 commentedon Oct 6, 2022
Hmm. I see. That would save you 5 operators, indeed. However, it might be less efficient since you now perform extra work in
operator+=
andoperator*=
. 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 inmain
.chavid commentedon Oct 6, 2022
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 commentedon Oct 6, 2023
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.