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 learncpp.com. I haven't read this one from parashift.com 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.

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.)

OOP344: Creating an editor

Before things get any more hectic with this OOP344 project (in which we're to create a programming editor, a la vi), a few things:

1) Compiling can be a pain in the butt

I have never compiled anywhere besides linux (on Seneca's matrix server) before, so learning to compile on Visual and Borland was a frustrating experience. More than anything else, it was being told that the library I was trying to #include did not exist.

To compile on Borland, I first had to create a batch file that would add to $path the path-file to my Borland compiler. I still have not figured out a way to set this permanently, so for now I must run it everytime I need to use Borland. It's a simple .bat file with one line:

set path=%path%;C:\Borland\BCC55\Bin

I had to create a bcc32.cfg file in the Bin. All it contains is:

-I"c:\Borland\Bcc55\include"
-L"c:\Borland\Bcc55\lib"

It cuts down the typing I have to do when compiling because it automatically includes the libraries I need to run my program.

Visual and Linux were easier, though with Linux, I forgot to "-lncurses" at first.

2) I'd been accidentally committing to trunk all along

What I'd done was copy and paste the PRJ file (which contains the .c's and .h's for the project) from trunk to my workspace. I thought that because it was in my workspace, committing any changes I made was ok. I was under the impression that anytime people committed to trunk, everyone's version of similarly named files in trunk would be updated, too. After all, how else is everyone going to get synched?

This issue has been fixed now. I've done a fresh checkout, and after all the editing I've done to my code, I'm going to be ready to merge my code with the trunk code soon.