Final Week

Class:
This last exam was quite a bit more difficult than the first exam. Regardless, it was a fair exam. I'm super glad that the professor had given us so many hints buried within the test cases. Those were definitely helpful. I wish I would have had more time to study for this exam but regretfully the third class I took this summer had a major presentation due during the week which took away from my study time. I am almost certain that if I had a little more time to study, I would have done better on this exam. I went in hoping for an A and walked out confident I would be in the B range for the course. Hopefully there will be a slight curve that might push me into the A range.

Overall Final Words:
I highly recommend this course for any student wanting to pursue a career in C++. What I have learned over the past year is that if you want to get a software engineering job that involves finance or stocks, you have to know C++ very well. The interesting thing about C++ is that its pretty much built on top of C which happens to be one of the fastest languages out there since its so close to the machine architecture. When it comes to handling money, employers want to see speed and security. A candidate with really good C++ skills is usually sought after. This class is the best way to take your C++ skills to the next level and make sure that your code works in a very modular way. When writing code developers usually must keep performance and memory use in mind. This class adds an additional requirement in which you must write code that is as generic as possible. This means that your code must be modeled like many of the functions within the standard library. Finally, I'd like to say thank you to the professor. Its very evident that you care about the success of your students and I want you to know that we all appreciate it. Thank you and keep it up.

Multiple Inheritance in C++

Introduction:

One of the most important SOLID principles is the Open-Closed principle which specifies that software entities (classes, modules, functions, etc...) should be open for extension, but closed for modification. As we learned in class, many of the software design paradigms make heavy use of extension as a way to make the code base more readable and less repetitive. The paper I read concerns itself with Multiple Inheritance In C++. Multiple Inheritance has always been a tricky subject for many developers. So much so that many languages don't even support it. For example, Java only allows for inheritance from a single parent class but allows you to implement multiple interfaces to make up for the lack of the feature. The concern with multiple inheritance occurs when a class D extends Class B and Class C, but Class B and Class C in turn have both inherited and perhaps overridden methods from Class A. The question arrises, which methods does Class D inherit? Methods that may have been inherited from Class A by B or C? or perhaps is it better to go straight to A? The short answer is that it inherits all of them. This problem is usually referred to as the deadly diamond where Class A and D represent the top and bottom corners respectfully of the inheritance hierarchy and the Class B and C make up the sides. Lets see what the creator and designer of C++, Bjarne Stroustrup has to say about Multiple Inheritance in C++ in this paper.

Salient Points:

Here is a short example of multiple inheritance can be achieved through C++. By no means is this example complete and you should refer to the paper for a better idea of how this is achieved.

Given two classes:

class A{...}

class B{...}

//a user can define a third class 

class C : A, B{...}

Calling a member function of A or C is identical to what is done in the single inheritance case. But if you are given a C* and want to access the inherited member function of B you have to be a little more explicit:

C* pc;

pc->bf(2)

//Assume that bf is a member of B and C has no other member named bf except the inherited one of B

In this case the compiler is able to figure out what it needs to do. The second line is converted and the pointer is advanced to the location in memory where bf is located. But what happens if both A and B have a public member ii:

class A { int ii; };

class B { char* ii; };

class C : A, B { };

Now class C has two members called ii, A::ii and B::ii. Then

C* pc;

pc->ii; // error: A::ii or B::ii ?

This will be illegal as there is ambiguity over which member is sought after. We need to be a bit more explicit:

pc->A::ii; // C’s A’s ii

pc->B::ii; // C’s B’s ii

What happens when we are not trying to access a member but instead a function f()?

class A { void f(); };

class B { int f(); };

class C : A, B { };

C* pc;

pc->f(); // error: A::f or B::f ?

pc->A::f(); // C’s A’s f

pc->B::f(); // C’s B’s f

This can however become cumbersome quickly and so as an alternative to explicitly identifying the base class every time, you can define an f() in C that calls the base functions as required.

class C : A, B {

int f() { A::f(); return B::f(); }

};

C* pc;

pc->f(); // C::f is called

As Stroustrup claims: "This solution usually leads to cleaner programs; it localizes the specification of the meaning of the name for objects of a derived class to the declaration of the derived class."

Finally addressing the problem of the deadly diamond. if class A and B inherit from another class say L, you can specify further up the chain which inherited method you want to use:

class L { ... };

class A : L { ... };

class B : L { ... };

class C : A , B { ... };

Assume that class L in the example above has a member m. Then a function C::f could refer to L::m by explicit qualification:

void C::f() { A::m = B::m; }

You could also be more explicit:

void C::f() { A::L::m = B::L::m; }

And so by being explicit you can specify exactly which method you are trying to call.

Conclusion:

First off, please be sure to read through the paper in its entirety as it outlines how to handle virtual functions which unfortunately we did not cover in our class this summer. The paper goes into good detail about how things can change when using virtual functions. Also, the paper was very helpful at understanding how memory is managed and where pointers are pointing to when dealing with multiple inheritance.

Multiple inheritance is definitely useful in many instances. Although C++ is a pretty complicated language and things are already tricky, it is important to be able to know how to use extension and inheritance. The trick to multiple inheritance in this case is to simply be more explicit about the members and functions you call. If you are going to extend a class its probably a good idea to be in the habit of being explicit in your method calls or to simply override any method you plan to use and be explicit within its definition. I'll give a final word on performance when it comes to multiple inheritance. Since much of the hard work is done at compile time it is important to note that performance is not hindered much in the final program. More importantly you should not be afraid to use multiple inheritance if you are worried about errors. The complier will force you to be explicit as it is so there shouldn't be any fear of messing up. With that said, C++ has its intricacies and so you should write plenty of good test cases and asserts to make sure your implementation is correct.

Week 9

Class:
Again this was a rather short week. We had a guest speaker come in on Wednesday from Indeed.com. For those of you who don't know Indeed is a job listing aggregator and search site. Since I am also in the morning class I did not stay for the presentation the second time around. The presentation was supposed to be over tools and processes used in the real world of developing. In the morning section however we seemed to digress and the presentation had turned into a sort of question/answer session in which the students would ask questions and the presenter would do his best to answer them. I feel that the presenter should have made a powerpoint presentation to help himself and the rest of us all stay on topic. The week started off covering sets and maps as we finished up the last of the containers. The week ended with talking about backinsertor, frontinsertor, and somewhat related istreamiterator and ostreamiterator. The key takeaway was how to write these to conform to the STL provided copy.

Project:
I am extremely upset with how this final project went and you'll soon see why. I got a head start on it. I actually finished it last week on Sunday. My greed got the best of me and I ran some of the tests that other class mates had posted and realized that perhaps I needed to test for random-access vertex iterators. After spending some time trying to hunt down a compile time bug, I learned from the professor that we didn't need to go that far. Content, I submitted the code that I had finished a week earlier and happily submitted confident that I would get full points. But somewhere along the line I forgot to add the grader as a collaborator to my repo and I received an email today stating that I will lose 20% because of that. If I had to guess why I didn't add the grader its probably because the grader wasn't listed on the project page early on when I had started the project. Regardless, I have learned my lesson and probably should have made the trivial "Add grader to repo" issue part of the initial 10 issues in the issue tracker on Github. Its always the penalization of easily avoidable mistakes that hurts harder than having points taken off for a poorly implemented solution. Oh well its not a huge deal, I feel pretty good about the class and am expecting an "A" anyways. All is well :)

Week 8

Class:
This was rather a short week. Class was cancelled as the professor had to take care of some official UT business on Friday. We also had a guest speaker on Wednesday. The guest speaker was from a local austin company that makes software for mobile devices for various clients. The topic of the lecture was about responding to change in the world of software development. Imagine that you have written thousands of lines of code for a specific platform and then all of a sudden the company that produces that platform decides to do a major change in its latest iteration of the platform. All of a sudden your code is broken. The task of having to conform to the new platform can be made much more manageable by using the SOLID principles discussed in class. Such was the case when Apple released IOS 7. Companies that had written code using the SOLID principles were able to quickly interchange small portions of code that connected their software to the underlying platform and the rest of the pieces worked as they should with minimal to no changes at all. Other companies had to start from scratch.

Project:
When the graph project was initially released it seemed a tad bit overwhelming. The skeleton code contained small hints from the professor with regards to what needed to happen but I had several questions. We ran out of time on Monday during class to ask questions so I had to resort to piazza. This time for the project I had decided to go solo. On my last project, I found myself and my partner working on the project at erratic hours and I didn't want to repeat this for the final project. After some struggling I asked myself "what would be the right way to do this?" and so I decided to first write the test cases. I read the specification provided carefully and tested every single function I could very carefully. As I created these test cases I had a way better feel for what the project required. The rest became a cakewalk and I was able to quickly finish the project. I'm officially ready to turn it in 4 DAYS EARLY!!! :)