siebenschlaefer
commented
6 months ago The example solution was just the simplest solution I could think of. There is a more general approach that treats this problem as a breadth-first search without inspecting its properties and a mathematical approach that solves a Diophantine equation (I was obsessed with this problem for a week in November and am kind of proud that I found this one.)
I definitely want to write either approaches or a blog post but not in the next two weeks.
As for the mentoring notes, I want to wait a little bit until we have a reasonable sample of solutions from which we can extract talking points.
vaeng
This is a translation of the "two-bucket" exercise.
I've decided to provide the complete
.hfile with a definition of theenum, thestructthat holds the result, and a declaration of the function. Although I like the idea of letting the students write their own.hfile by extracting the interface from the tests I think in this case it would be just chore. But feel free to object, that's not a strong preference of mine.The thing that bothered me the most is how to handle cases that are not possible to solve. Requiring exceptions for "expected" error cases that might occur frequently and are part of the normal control flow is IMHO bad style. If I could I would use C++23's
std::expectedbut that's not an option at the moment. Here are some alternatives:possibleto the return type (that's what the C version does). But it feels C-ish.booland use output parameters for the actual result. Again, C-ish and IMHO bad style.std::optionalthat is empty if the task is impossible. But I'm not sure if the semantics were clear and it would be harder for students who do not knowstd::optional.If any of you has an idea, I'm all ears.