Tag Archives: pointers

handle classes

This entry comes a bit late as this final week of school has been keeping me on my toes and I was a bit delayed in publishing this to being with, hopefully any readers might forgive this tardiness and the berevity of this post.

The week of the 22 Apr was a fun-filled week full of last minute touches to the project as we began to go over the different approaches to pointers.

The first of which was a simple ‘has a’ relationship in which the handle class(henceforth ‘Handle1’) contained the pointer. This approach was nice because it helped to solve the problem of memory managment (from the perspective of the main program) and pushed this down into the Handle1 object and the containing class(as its destructor invoked the destructor of the handle). The drawbacks to this implementation was that to give access to the methods of the pointer we would either have to loosen the encapsulation of the pointer or define a common interface, we choose the common interface initially.

Handle2 was the second revision in which we loosened the encapsulation instead allowing pointer like operations with operator* and operator->. The good: this allowed us to not have to define the public interface, as such allowing for non-shared methods of the interface to be invoked (after verifying the type and typcasting). The bad: by giving up the pointer we lost control of the data and the user could swap it out and then we would have the potential to leak memory.

The third and final handle(Handle3) was our attempt at a copy on write pointer encapsulation. The objective being, since we often have a spare matrix in which many cells never get written it would be nice to not have to have a unique value of a null object for each non-used cell. The overhead is that we would need to track how many locations are using the same pointer by a separate count and as such increase the level of indirection so we could modify this count only once for all instances of the pointer and then only alter the one that we need to when written

In summation it would have been nice to use a copy on write pointer that implemented the common interface for the Life project, due to deadlines we went with a similar but not optimal approach in which we had the multiple levels of indirection and a common interface but initialized all of the pointers to null objects initially.

 

templating vs pointers, array object vs primitive storage, and the glory of STL vectors in C++

This post shall be rather short in its nature as it is already past due and I am still trying to finish up my workload that I had on my “break”. Two weeks ago in OOP we took some time to observe the nuances of array initialization with a high point being demonstrated by quiz 20, namely showing that an array of type A instantiated with Bs would create the invocation pattern: B constructor, A constructor, A copy Constructor, B destructor and lastly when the Array exited the function scope of invocation A destructor would be called.We also looked at templating examples and pointers. The high point there being that templating allowed for more types of iterators than pointers, but that some iterators imposed restrictions on the order in which their functions were called, namely the read iterator, and the * and == operators. We also briefly discussed why the STL was nice, and the fact that vectors are similar but much faster than java ArrayLists. The high points being attempt to use STL or Boost to save some troubles and a reference to the fact that C++ vectors subscript([]) operator did not suffer from the linear time look-up like java’s List interface does, however there is some overhead on the .at operator.

 

Arrays and Pointers galore

This week in OOP, we spent most of our time iterating over the different types of pointers in C++ and motivating some examples, the discussion stems from the fact that there are 4 varients of pointers in c++ which can be summed up by the following code and comments:

int c;

int* b; // read/write, many locations

cont int* pc; // read only, many locations

int* const cp = &c; // read/write one location (same as doing int& cp = c;)

const int* const cpc = &c; // read only, one location

We took some time later on to discuss the fact that in java arrays are allocations of values only if the data members are primitive types and for all non-primitives the array holds references to the type, unlike in c++ where the arrays contain the values themselves and can either be stack allocated or heap allocated, unlike java where all stack values reside on the heap.We finished up the week by looking at pointers vs. arrays in c++ noting that pointers are rvalues where arrays seem to be lvalues.