Monday, March 15, 2010

Container Classes

IRC meetings have become so slow that Fardad Soleimanloo has now decided to try using voice conferences through Skype! Though OOP344 is not an open source course (like OSD600), the project for it sure is starting to look and work like one. (Just this morning I had to chuckle at my team--scheduling a meeting that works with everyone's schedules is a nightmare.) I find the course incredible because in all my years of studying, I've never seen a teacher put so much time into a course or students asked to put so much into it either. In university for Economics, I mastered the art of cramming for every midterm and test (those were all you were getting marked on, after all). I studied strategically and aced most of them, but I didn't retain much info in the end. I'm finding that in college, with weekly due dates for each course, you have to keep at it or fall behind if you let things slide even by a week.

Anyway, the real point of this post was to share a couple of nifty little webpages about container classes. In our last IRC meeting, my group had a bouncy, yellow question mark over our collective heads because we just didn't grasp the idea of them soon enough. But the fact is, container classes really are how Fardad described: they are an array (another kind of container) for objects. Here is the webpage, complete with a sample class, from I haven't read this one from yet, but the writing seemed pretty funny, especially after learning the basics of a container class.

I haven't read the textbook section for stacks and queues yet (and yes, that means I haven't coded how a queue works yet, either), but the above webpages really helped me understand the basic idea for them. I hope they help someone else, too.

Wednesday, March 3, 2010

OOP344: Logic problem

Part of my contribution to this first programming project was to code the section of the function that would actually let the user insert characters into a line. (Project specs here. The function I'm working on with everyone is bio_edit()). On and off during the week of the due date, I had successes, but the last hurdle stumped me. At some point in time, everything was working perfectly--it's simple logic--and then I just had to re-do someone else's code, and everything with regards to insertMode stopped working.

Someone suggested using memmove when shifting the string, but since I was (and still am) afraid to use a function I hadn't used before, I decided to stick to a for-loop. It didn't work as well as I thought. I coded it so that when inserting characters, everything from the end of the string to the current cursor position was shifted to the right, and the character typed would be inserted in the current cursor position (*curpos). However, the characters being shifted included those beyond *curpos, and any letters I typed were basically overwritten by whatever was to the left of the cursor.

I isolated this section still got the same results. My code looked like this:
Then I got it fixed with this:

Line 645 now takes into account *offset where it didn't use to (line 508 in the first screenshot). The really bad part about trying to debug this was programmer failure--I kept forgetting the fact that *curpos is related only to length of the editing field and not the str being edited. *offset + *curpos is the index of any character in str. Whenever I tried doing a walkthrough, everything made sense. At some point, I stared at my long enough to realize it. Massive failure.

Though the project has been submitted, I'm still going to attempt using memmove to reduce the number of lines. (That is, if playing Prototype doesn't get in the way, haha.)