Pit Playoff Bug

So I spent the last two lunchtimes trying to figure out what was wrong in Pit playoff code that worked in season’s past. This really irks me because I had Part-Time Developer plans in mind. I believe I’ve found the problem and should be able to run the first round of the vaunted Pit playoffs tonight, and get everything back on track.

The problem occurred when I was running the main Pit playoffs. It found the first series, ran the fight, then prompted me to input the fighters for the next fight of the same series. It was only supposed to run the first fight in the series then go to the next series.

I beat my head against the wall most of Sunday night trying to figure it out.  Then Monday over my lunch I pretty much nailed down the problem, and then today over lunch I put in the fix and tested it.  I think it’s got a clean bill of health now, at least hopefully through the rest of the playoffs.

The problem turned out to be a very rookie mistake on my part.  Somehow it had worked through the first 6 seasons of playoffs.  I attribute this surfacing due to switching from VS2003 to VS2005 at the beginning of this season.   When I made the switch I had to change includes such as “include fstream.h” to “include <fstream>”.  I’m guessing something with the basic C++ includes changed as to why I had to change my includes.  I hadn’t kept up with the language enough to understand why I had to change things.  So it would seem the old fstream library somehow hid my boneheaded programming bug.  How I don’t know.  It seems to defy the way it should’ve behaved.

The problem was in the way I was using my file handler class that I use for the binary flat files that hold the Pit data.  (Binary flat files?  It seemed like a good idea at the time.)  I had a file handler for my playoff series file (basically a summary file).  I was looping through the file looking for a series that matched the season and playoff round I was in as well as not being already completed.  Once I found a series that wasn’t done, I would loop through my playoff games file (basically a detail file) with another file hander.  When it found the next game it would run it.  Once done I would need to update the playoff series file, which keeps track of the current win/loss situation.  However, I used the same file handler that I was using to loop through the same file.  After the update, it threw my location earlier in the file for some reason.  (I believe that the position pointer is undefined at this point and can’t be relied upon.)  Logically I would think it would put the position to the end of the record it wrote leaving me where I want to be to loop on, but from experience I know you can’t count on this.  It was throwing it much earlier in the file, which caused it to loop and eventually find the same playoff series again.  Something really got hosed though, because even when I would cancel, supposedly continuing the loop it would jump back again, continually finding that first series.  And it just got worse from there, duplicating records and caused the file to double in size with duplicate records.  Not quite sure where that came from, but I understand the base problem.

So I now have a different file handler doing the update and we’re now happy.  I could give the excuse that I wasn’t super familiar with serial filestream io at that time of the original coding, but I had been doing DEC Fortran with flat files for a few years at that time and you always had to be aware of that sort of problem.

If my reasoning on this is way off, please let me know so I can fix my understanding of the problem.

Advertisements

Tags:


%d bloggers like this: