Bugfix Notice

It has happened again. Twice now, and in a very short period of time at that, I committed some errors in the code for Programming Challenge 12.13. Unlike the last time, I decided to edit the original code, and resubmit it, which is unfortunate. 

The nature of the error resulted from a poor design decision I originally made while in the planning stages. It was looking like a great idea to have a nested structure from which two other structures would be called. What I did not know, or hadn't realized, is the fact that you can have a nested structure, but this brings along many troubles if you're doing it wrong.

Here is part of the original code:

As you will notice there is a structure called Item, which holds two nested structure members. One calls the Date structure, the other calls the Inventory structure. In the code that follows, the Item structure was passed down to all the other functions, and this is what introduced the error. The way the original code was, I had this statement in the write function:

writeRec.write(reinterpret_cast<char *>(&itemRec), sizeof(itemRec));

This must have also written part of the Date information to the file. The same must have happened with the edit function, which contains a very similar line of code to the above. When I started writing code for the Programming Challenge 12.14, it became clear that the records haven't been read in correctly. All data was displayed in the wrong field, item description in the dateAdded field for instance. The 'easy fix' would have been to add the Date structure to the current Programming Challenges' code. With it in place, all data contained in the file was displayed correctly. 

Since it is important only in the original program, but only an artifact in the current program, some changes to the old code was the better way to handle things. A new filed was also added to the Programming Challenge 12.13 code: The 'numRecords' field, which is now contained in the Inventory structure. The idea is to have some sort of 'limit' in place, which is something that I think is beneficial to the current Programming Challenge code.

 

Unlike last time it also had a positive effect. I do know now that structures, if used in the way I did, can cause unexpected trouble. Also I learned that, if there is a Programming Challenge 1 and a Programming Challenge 2 that builds on the first code, I should try functionality in both, before submitting one Challenge, only to find that things would not work in the program that follows it.  

To my readers, if you happen to have run the original code or using the example file: PR_Item.dat, please download it again, and give it another try. Also here is the original Programming Challenge 12.13 code for review purposes. I can only promise and hope that such mistakes will not happen again. I would also like to say how sorry I am for introducing such problems. 

Now it is back to the IDE to write and finish Programming Challenge 12.14, which should go live very soon. My fellow learners I wish that they be wiser and know when and how to use structures the right way, especially when dealing with input and output to files.