Friday, November 27, 2009

Assignment progress

Looked at IO_Vedit last night to try and get some work done. I was confused by a few things; We can't have conditional inheritance in the sense that. a Frame is always created but if you display() it or not is based on bool framed. However that being said, we do need to change IO_Field(row, col) at the moment of creation based on wether the field is framed or not(row+1 and col+1, because of the frame). So how do I go about doing that? is there some way to control that without creating an extra set() function within IO_Field. Moreover another confusion I had was, how do I go about calling io_edit::display() when io_vedit and io_edit are not related?

Thursday, November 19, 2009

Progress on Assign2

I encountered several several problems in Assignment2 so far.

was creating the project skeleton and understanding that pure virtual functions of IO_Field require child classes to create and implement each function. So in a sense you ensure children are using the current most relevant function at the time. These pure virtual functions are identified as:

randomFunctionName(int randomArgument) = 0;

I was having trouble deleting IO_Label::_data. _data is a void* within IO_Field which label inherits. So to my understanding a label always contains a field with or without data in it.

I haven't got to the problem yet. So I decided to copy strings passed to new labels into _data. Of course _data had to also be casted as a char* ! So that being said the label constructors would equal _data of its parent with str via:

(char*)this->_data = str; //or something to that effect

with the hopes it would call the overloaded operator= in label, then calling set which would simply strcpy str into a char* casted _data (because its a void pointer). This is where the problem was born.

the label operator= requires a label OBJECT as its left hand argument. So my call did not give any errors but at the same time it negated the overloaded operator=, because it simply assigned _data whatever str was. Which at the time is exactly what you need.

However as the constructor went out of scope str is destroyed and by extension the data that _data pointed to because you assigned to the same thing str. Then delete[] ing _data when label goes out of scope blew up, because you can't delete something that has already been deleted.

So that problem plagued me until I finally debugged and step from the CREATION of label to see the assignment of _data fail rather then step through the DELETION of label where I thought the problem existed.

so the proper call of operator= is and should have been

*this = str;

easy mistake, big headache.

My current problem is that i'm having a brain fart as to how to get IO_Field getOwnerTop and the rest of the optional functions working. I can't wrap my head around how to access the members of io_form(its parent io_frames top, left etc) from the IO_Form* _owner. member variable in io_field.

Saturday, November 7, 2009

starting assignment2

Putting together the assignment 2 skeleton, so that my questionably devoted group can start working was a joyous learning experience (read: horrendous aneurysm inducing experience).

After crawling through the classes and creating the header files. I was introduced to the joy of including the assignment 2 structure into our project(cpp and header files). Meaning the mess of my circular includes AND lack of includes through use of undeclared identifiers.

Basically there a few rules for handling includes:

In Header Files
  • use forward declarations when you can. Meaning if you only refer to the class you can use this option.
  • #include "*.h" your base classes.
  • In our case because we have need identifiers from io_def.h, we should include that in every necessary header file.

In Cpp Files
  • #include "*.h" your respective header file ie: inslude io_form.h in io_form.cpp.
  • #include "*.h" your forward declarations from your included header file.
io_form.h for example:

#ifndef __IO_FORM_H
#define __IO_FORM_H
#include "io_frame.h"
#include "io_def.h"

class IO_Field;
class IO_Label;
class IO_Form : IO_Frame{





And io_form.cpp:

#include "io_field.h"
#include "io_label.h"
#include "io_form.h"



I hope this helps somebody! Next on the to do list: divide Assign2 and fix << operators and my mess with pure virtual functions.

Thursday, November 5, 2009

Taste of IRC meetings

I haven't blogged in awhile, having 6 classes and a job is brutal this semester, so to catch up im sitting the library getting this started.

First things first

My initial impression from IRC meetings is:
everything takes time... having a 2 hour meeting at 11pm was not a good idea in hind sight. Additionally a meeting late Halloween night had stellar attendance. Oh well live and learn.

That being said they have a lot of potential and I look forward to meeting with Fardad to discuss the subtleties of Assignment 2. Some things to consider for meeting: using an array vs LList, dividing up A2 in chunks allowing it to remain functional while we work on it.

Friday, September 18, 2009

OOP344 io_display challenge

As a late night attempt at challenge 2, I decided to have some fun with ternary operators. This is far from efficient code best case you run 2 checks, worst case its 3 checks EVERY run through the cycle. So at the cost of efficiency I played around minimizing the number of readable lines of code.

The source code can be found here.

void io_display(const char *str, int row, int col, int len){
io_move(row, col);

At first I attempted to use string library functions... with mixed success. Eventually I totally abandoned them and opted for this alternative.

Monday, September 14, 2009

First Blog Evar!

After a trailing 10 mins. I set up my Blog account, Now onto the feeds.