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.
First:
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:
virtual randomFunctionName(int randomArgument) = 0;
Second:
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.
Third:
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.
First:
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:
virtual randomFunctionName(int randomArgument) = 0;
Second:
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.
Third:
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.
Labels:
OOP344
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
In Cpp Files
#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{
...
};
...
#endif
And io_form.cpp:
#include "io_field.h"
#include "io_label.h"
#include "io_form.h"
...
EOF
I hope this helps somebody! Next on the to do list: divide Assign2 and fix << operators and my mess with pure virtual functions.
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.
#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{
...
};
...
#endif
And io_form.cpp:
#include "io_field.h"
#include "io_label.h"
#include "io_form.h"
...
EOF
I hope this helps somebody! Next on the to do list: divide Assign2 and fix << operators and my mess with pure virtual functions.
Labels:
OOP344
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.
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.
Labels:
OOP344
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);
do{len<0?io_putstr(str):io_putch(*str?*str++:'\0');}while(--len>0);
}
At first I attempted to use string library functions... with mixed success. Eventually I totally abandoned them and opted for this alternative.
The source code can be found here.
void io_display(const char *str, int row, int col, int len){
io_move(row, col);
do{len<0?io_putstr(str):io_putch(*str?*str++:'\0');}while(--len>0);
}
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.
Labels:
blogging virgin
Subscribe to:
Posts (Atom)