Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

About operators exercise #439

Open
1 of 8 tasks
chavid opened this issue Mar 8, 2023 · 9 comments
Open
1 of 8 tasks

About operators exercise #439

chavid opened this issue Mar 8, 2023 · 9 comments

Comments

@chavid
Copy link
Contributor

chavid commented Mar 8, 2023

I found it too too long. Few suggestions to better focus on operators only:

  • Provide in the original code the normalize() function and std::gcd stuff.
  • Provide int the original code the constructors, public attributes, constructors, assign method, and externals functions such as multiply, add, compare (returning -1,0,1 ?), print.
  • Ask to replace the functions with operators: =, +, *, <=>, <<
  • Then ask to add, reusing previous ones: !=, +=, *=.
  • Show that with <=> implemented, then <, <=, >, >= are automatically infered ?
  • Optionally, make all the assignments returning *this, like in operator<<, and explain this permit chaining.
  • Optionally, make them move the operators as inline friend functions, and make attributes private.
  • Optionnaly, discuss the pros and cons of making the unary constructor explicit.
@chavid
Copy link
Contributor Author

chavid commented Mar 8, 2023

I may work on a proposal later on, if you wish.

@bernhardmgruber
Copy link
Contributor

I would like to add, that we should prefill the class declaration with two data members for numerator and denominator, probably as int. I had a few students implementing the class with a float.

Furthermore, I think we could remove operator+ and operator+=, or move them to the back as bonus exercises.

@bernhardmgruber
Copy link
Contributor

My improvements are up here: #442

@bernhardmgruber
Copy link
Contributor

obviously too hard for beginners who never wrote a single class.

Right. I think we should therefore have an exercise before where the students design their own (simple) class, like you say below.

  • in the first one, we just learn to create a class with constructors, private attributes, accessors, and externals functions such as multiply, add, compare, print.

It does not need to be a Fraction class. It can be anything! We could also cover this as part of the polymorhism exercise, by asking the students to add a new class to the hierarchy.

  • provide in the original code the normalize() function and std::gcd stuff. thatś not the purpose to loose time with this.

Agreed, part of #442.

  • make them implement operators as external functions, relying on accessors, and do not discuss the option of implementing them as members, or friend functions. Beginners are not mature enough to understand this. better if they have time to play with tools and polymorphism, etc.

The exercise leaves it open how to implement the operators, by design. There is also no need to explain how hidden friends work. Students would only know if they looked at the solution, which they should not :)

  • do not talk about chaining =, +=. do it only for <<, it is largely hard enough for beginners. again, better if they have time to play with tools and polymorphism, etc. Or clearly advertise it as a final advanced optional step.

I removed the chaining of operator*= as well.

@chavid
Copy link
Contributor Author

chavid commented Mar 8, 2023

Starting with a Fraction class would have the benefit that when they move later on to operators exercise, they are already familiar with the use case. I would not put this in polymorphism, cause I prefer to keep inheritance away when they try their first class.

@chavid
Copy link
Contributor Author

chavid commented Mar 8, 2023

Yet their first class may be inspired by polymorphism. For example provide a Pentagon and ask them to write an Hexagon, with no base class and no inheritance at the beginning... Well, as you prefer. Both have different benefits.

@bernhardmgruber
Copy link
Contributor

An additional difficulty is that the operators exercise is also used in the advanced course. It has two audiences. We could try to make some "more difficult" parts optional, or add an extra second part that is only used in the advanced course.

@chavid
Copy link
Contributor Author

chavid commented Feb 12, 2025

I upgraded the top message, so to make it clearer, and take into account what has already been solved by Bernhard.

@chavid chavid removed the stale label Feb 12, 2025
@chavid chavid changed the title Operators exercise About operators exercise Feb 12, 2025
@chavid
Copy link
Contributor Author

chavid commented Feb 12, 2025

If you agree with the proposal, I may prepare some merge request accordingly:

  • Provide int the original code the constructors, public attributes, constructors, assign method, and externals functions such as multiply, add, compare (returning -1,0,1 ?), print.
  • Ask to replace the functions with operators: =, +, *, <=>, <<
  • Then ask to add, reusing previous ones: !=, +=, *=.
  • Show that with <=> implemented, then <, <=, >, >= are automatically infered ?
  • Optionally, make all the assignments returning *this, like in operator<<, and explain this permit chaining.
  • Optionally, make them move the operators as inline friend functions, and make attributes private.
  • Optionnaly, discuss the pros and cons of making the unary constructor explicit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants