No Monkey Business

Despite the title of this last challenge, it was all but easy to do it right. There were so many small hurdles in the way that it is difficult for me to name every single one but I will try. Every one caused me to stumble, fall, stand up and retry or rewrite the whole program from scratch.

The very first time i fell was on my first try. About half way through I tried to output to screen the data that was stored for the largest, smallest, average amounts eaten. This worked well for pounds eaten so i tried using the same for the other instances in the code. Consider the following line of code:

cout << "\nOn " << (days[weekdays]) << " ate lbs: " << averageEaten[days];

This was used in the outer loop. The variable days was no array variable, weekdays was. So you could expect that to be causing any problem, wrong output or something. Not at all. It worked in the scope of the function, inside the outer loop. But when used outside it, in the same function, only this time around with loops to iterate through the contents of the relevant subscripts of these arrays, either one of the following problems occurred:

1.) The program would enter an infinite loop
2.) The program displays gibberish and crashes (with some infamous .dll error)

It did not help to change the line of code to something like:

cout << "\nOn " << (weekdays[days]) << " ate lbs: " << averageEaten[days];

So i skipped all the output, left it there, instead stepped through every instance with my debugger to see that my arrays were receiving valid and wanted data. Well, this was simply a way of protracting the problem. There was still the report to be created, separate function - of course, which then showed the flaws in my first revision of code and I had no output that was usable in any way, or rather that would not cause the program to crash on certain instances during execution.

The biggest hurdle at that point was figuring out how to get the smallest amount eaten by each individual monkey. You should think that it works just the same way as the other way when determining the largest amount of food eaten. No, no, no! It is more complex - at least with two dimensional arrays it is not as straightforward as with one dimensional ones. No matter looking at a two-dimensional array as arrays of arrays - one in another. 

This was not the only flaw this first revision had. I was using, what is so called magic-numbers. Meaning that I read there in my book to avoid global variables at all cost. That it meant "... don't use global variables like: int G_WHAT_HAVE_YOU, but instead const int WHAT_HAVE_YOU ..." so the values remain unchanged and no danger occurs from using them, by doing some research about this I found out and used them accordingly in the new revision.

Full of spirit I scrapped the code, added a new file to the project, and started over again.  Another revision more trouble, or rather more of the same trouble as before. My function prototypes were a mess, I used array size declarations which were not needed for instance. Here is an example of one such early function:

Suffice to say that this revision didn't work, the next, the one after that, until I ran out of ideas as to how I should ever solve the challenge. Then I started doing it the other way around. I had worked out all the different parts, meaning getting the least, greatest and average amounts, the total, and even the output in a limited scope. So in my desperate attempt to get something done, I wrote all the arrays, declared their sizes and then kept everything in main instead of separate functions. Would you believe it? Everything worked fine there ... Great. But what with modular programming? Keeping as much of the code out of main and in separate functions, each doing their own thing? Well, it was a template, and a working one. Template file: Monkey.cpp

Then I again tried to separate it all into functions, which worked, as in several of the other revisions. All that would not work, no, that I haven't worked out is is the way to display it. How to get all the data together in one function was the problem, and it was one of the biggest ones all along. This was because of bad choices I made when declaring my variables and functions. At least I guess this was what caused most of it not working the way it was supposed to be.

Yesterday, then desperate and out of ideas, after about 10 to 12 revisions of the same challenge, numerous documents with parts of code, after a particularly bad day when I almost had it all done, closed the IDE and when I opened it, most of the code was back to some hours before ... I closed it i pasted something over working portions of the code, all was gone and I had no idea how I solved the get least amount problem ... Back to square one with this one. Here is what remains from this darkest of days, one single screenshot depicting how far things have grown:

 
So, yesterday I started my next attempt. No, I did not have a plan or clue, so I started playing around. Actually with range-based loops to see what this would do in terms of output. Then I started for real, thinking and looking at all the code that has amassed during the last couple of days. First thing I did was declaring the arrays for monkey names and day names, then working all with output in mind, which should be the final part. And slowly but steadily I found true solutions, no messy ones, no half-heart tries in the hope that I could somehow wing it for certain parts. After some hours of work it was finally finished! You can not imagine my sigh of relief that this Monkey Business was over.

Now, would there have been an easier way to find a solution? Without working hours upon hours on the same problem, and after numerous revisions hardly any ground gained? Certainly. If only I would have asked around for solutions, or simply looking up solutions, then it would have been solved very fast. Why didn't I do this then you might ask? Because then I would have been told what the solution is, I would have implemented it, and what would I have learned from that? Nothing. The challenge, every challenge is, to find one's own solution. Understand, or try hard to, what is going on, how, when and why errors occur. It is these lessons that stick the most, and are most valuable in the long run, to figure things out that way. Because even though every single challenge is limited in scope, what with future projects? If you can't figure out how to write code for one problem, how - then will you be able to apply it in other projects? Similar but not quite? Mind you, I don't say that it would hurt to ask when needed! Figuring it out oneself first, even it takes numerous tries first, is better.

Now, with this difficult challenge out of the way, on the journey goes. I hope that most of the upcoming challenges will be easier to solve - or less troublesome. To my fellow learners, I wish all of you to not stumble and fall over so many hurdles as I did. Give it your all, and success will come in due time.