I don’t think it represents CPP in a good way. Given that the exercise requires Boost’s date module it makes sense to use the features of that library. Then we just end up writing loads of wrappers. I think the most I got out of it was some VIM practise :-(
I’m wondering if some the methods I used from boost were added later after this exercise was created.
I sometimes work on the C++ track as a maintainer and I recently translated this exercise for the sqlite track.
I see where your irritation comes from, I would probably have asked for a single function with three to four arguments (date / year month, weekday, and modifier).
The original implementation was done by Patrick Jackson and Erik. I think Patrick is not active any longer, so maybe @ErikSchierboom can say something about the intentions.
I would be open to changing the API, which would invalidate all the existing solutions. What do you think @siebenschlaefer, you probably have mentored this exercise a few hundred times.
I’m not sure if the goal of the exercise is to expose the student to the Boost libraries, but C++20 introduces calendar support in the header chrono. So, if using Boost isn’t the objective and if Exercism plans to support C++20 in the near future, it might be worth to consider using the standard library instead.
The exercise is a “track-wide” prototype. How each track actually implements it, is up to the translating person.
As the test runner can compile with Boost, it is an option for everyone to do so. Until C++20 is fully supported by the oldest Ubuntu LTS version, we do not plan on switching.
So April '25 will be the date for us to switch to whatever is possible with Ubuntu 22.04, away from 20.04.
Believe me, I would love to, but we want to keep users with older systems.
I believe C++20 will only be fully supported by GCC 14, to be released this year. So I’m guessing that Ubuntu 26.04 will be the first LTS to use it as default.
My big issue with the whole exercise and tests is the huge number of wrapper functions that have to be written.
An there is NO need, the variance in the functions should be covered by arguments.
I find it very very difficult to justify the code I have written to pass the tests.
I looked through a quite a few of the community solutions too, and its seems to have some of the most diverse submissions I have ever seen.
So far the best I’ve seen is someone used the macro pre-processor to create the slew of functions required…but still ….
I find it so difficult to justify the resulting code - who would use code like code like this?
BTW this is the first Exercism that made me feel “Grumpy” lol
( Oh i’ve just remembered Rust’s Linked Lists rofl)
I am completely with you, I do not like the structure either.
If we re-write the code it would break all the existing solutions, but make it easier for the future. I would like to hear Siebenschläfer’s opinion on it, as he has probably interacted with many students who solved the existing state.
I would like to hear Siebenschläfer’s opinion on it, as he has probably interacted with many students who solved the existing state.
Interestingly among my 8.500 review sessions only three were for the exercise “meetup”. It seems to be unpopular, or students are just not interested in a review for this exercise.
My personal opinion: Writing the 6 * 7 member functions is a chore. Once you figured out how to write first_monday() the other six first_xxxday() functions are mostly a matter of copy’n’paste. That results in a lot of boilerplate code.
Languages like Python that allow the interception of method-calls and have some runtime introspection are better equipped to handle calls to so many different member functions.
The C version is much simpler, it requires a single function that takes four arguments.
There are currently only about 240 published solutions for this exercise so IMHO we could still change a lot without affecting too many of them.
I’m not sure if the goal of the exercise is to expose the student to the Boost libraries
Like many practice exercises I don’t think it has one clear goal, students can choose what aspect interests them the most. Maybe that’s learning about boost::gregorian or how to do the calendrical calculations themselves. IIRC for me, 9 years ago, it was playing with boost/preprocessor/seq/for_each.hpp to keep the code small and reduce the repetition.
Okay, we are on the same page.
I will do a PR in the style of the C version. Unless someone else wants to do it first. Any takers? Maybe @AdrianJMartin