Monthly Archives: May 2012

Reflections and Closing Comments

Thinking back on why I joined this class I recall that I felt my knowledge of C++ was shaky at best and most of the solutions I had put forward in previous classes had been sub par at best. Hoping to stifle this lack I charged forward scheduling my last and final semester around this class and Automata.

After having completed the course I can say that I was pleasantly surprised at how much I have learned and just how comfortable I am with C++. I now dare to say that I am approaching the same comfort level that I have with Java and PHP and my career which starts with a C++ stack seems less daunting now.

Often I have heard it expressed that teaching someone who doesn’t have any programming experience is much easier than teaching someone with prior experience in another programing language, and this had agreed with my thinking in the classes where I had undertaken learning C, Ruby, and LISP. With the teaching methods used though In this class I found that this was somewhat true still as evident by the memory management errors I encountered in my projects but I felt that the discussions in class(although delayed sufficiently) helped to ease this pain and prove that the idiom asserted above is not necessarily true given the right guidance.

I feel that the most valuable topics covered were the design patterns (implicit in the projects), the lectures on memory management, and best practices. While the lectures of lesser value to me were the lectures where we detailed the specifications of the projects.I would simply say that reading the documentation and querying peers has been critical in all of the internships I have held before and thus I was not anticipating spending two lectures orienting us at the anticipated solutions. I think Piazza, Stack Overflow, discussions with our partners, searches on Google, the project specs, and peer discussion should have been sufficient for this type of discussion/discernment. That being said this is an extremely minor nuance in the scope of things, and in my mind this class has been wildly successful in my eyes and has taught me a whole slew of things I would not have known otherwise.


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.