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.
Sunday, August 17, 2014
Friday, August 15, 2014
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.
Sunday, August 10, 2014
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 :)
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 :)
Sunday, August 3, 2014
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!!! :)
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!!! :)
Sunday, July 27, 2014
Week 7
Class:
This week started off with a much needed explanation of the deque project. Many of the students in the class were freaking out because after spending some time looking at the skeleton code they felt some of the code looked foreign and could use some clarification. We spent Monday walking through the STL vector and how it was implemented. This proved to be an excellent exercise as I had made sure to take lots of notes while the professor talked about every aspect of vector. The week continued as we discussed some of the other C++ data structures that used containment to get their work done. Structures like stack, queue, and priority queue are all backed by either vector, deque, or list and we explored the possible Pros and Cons of using each backing structure over the other. The week ended off with some performance boosting information on making functions faster by declaring them as structures and sending into the higher order function an instance of the lower order function.
Project:
Deque proved to be extremely challenging in the short amount of time that we had. My partner and I got to an early start over the weekend and came up with some really novel ways to approach the deque project. After stepping on toes and bashing out some early implementations of our ideas we realized we were going nowhere. Luckily in Mondays lecture the professor dropped a small hint. "Implement a stupid version of deque that uses a single resizing container and write all the methods in a way that passes the buck to just a few key methods in Deque and get that to work, then you can build the version that will give you credit." Although my partner seemed reluctant, worrying that implementing the stupid solution would take too long, I pushed ahead and made the stupid version literally in 5 hours and had it up and running. Now that I felt confident in my understanding of deque, and my partner felt confident in me, we were able to quickly push through finishing up deque together having only to rewrite just a few special methods to make the magic happen.
This week started off with a much needed explanation of the deque project. Many of the students in the class were freaking out because after spending some time looking at the skeleton code they felt some of the code looked foreign and could use some clarification. We spent Monday walking through the STL vector and how it was implemented. This proved to be an excellent exercise as I had made sure to take lots of notes while the professor talked about every aspect of vector. The week continued as we discussed some of the other C++ data structures that used containment to get their work done. Structures like stack, queue, and priority queue are all backed by either vector, deque, or list and we explored the possible Pros and Cons of using each backing structure over the other. The week ended off with some performance boosting information on making functions faster by declaring them as structures and sending into the higher order function an instance of the lower order function.
Project:
Deque proved to be extremely challenging in the short amount of time that we had. My partner and I got to an early start over the weekend and came up with some really novel ways to approach the deque project. After stepping on toes and bashing out some early implementations of our ideas we realized we were going nowhere. Luckily in Mondays lecture the professor dropped a small hint. "Implement a stupid version of deque that uses a single resizing container and write all the methods in a way that passes the buck to just a few key methods in Deque and get that to work, then you can build the version that will give you credit." Although my partner seemed reluctant, worrying that implementing the stupid solution would take too long, I pushed ahead and made the stupid version literally in 5 hours and had it up and running. Now that I felt confident in my understanding of deque, and my partner felt confident in me, we were able to quickly push through finishing up deque together having only to rewrite just a few special methods to make the magic happen.
Sunday, July 20, 2014
Week 6
Class:
This past Friday was our exam in the class and I'm really annoyed... Not with the exam, or the format, but with myself for not being as prepared for it as I would have liked. This class for whatever reason has made me super competitive and I was really counting on making a high score on this exam to solidify my rank/standing in the course. So basically I spent WAY more time prepping for the software engineering exam (same day) as I did for this exam and now I really regret it. As I mentioned, the exam wasn't too difficult, nor did it cover material that was completely unexpected. I just wish I would have studied class structures a little better before the exam. The exam format was definitely an upgrade from previous years where we were asked to choose the correct output (multiple choice) after reviewing some code similar to our quizzes. This time the entire exam was like a giant test suite that you could put in a C++ file and actually compile and run. The idea was to code up some solutions to the methods the professor asked us to write and then write test cases for those methods. One of reasons why I like this new format is because even if you don't know how to code a solution, you could create test cases for it and gain some quick points. Furthermore the exam actually prepared you for a real life career choice. If you walked away from this exam with the majority of your points on the exam coming from writing test cases, then this may indicate that you are better suited for a Software Development Engineer in Test role rather than a Software Development Engineer role. Anyways, I learned my lesson and will definitely need to hop on studying for the next test WAY ahead of schedule to get as close to that A grade as possible.
Project:
Not happy about our next project at all. For starters, we only have one week to complete the project as the professor released the project just a few days before the exam. Given that I am in both classes, I had two exams to study for which meant having to prioritize the exams over the projects. As a result I began working on the new project on Saturday. After spending several hours trying to wrap my head around the code I realized the task of implementing the standard library version of deque would not be as easy as BigInteger. There seems to be far less direction on this project. Furthermore, the test suite was of no help. It contains only two test cases and provided no hints as to how to implement the deque. Given the time constraint of one week I expected there to at least be a solid set of test cases given to us. Regardless the professor has informed us that he will be going over the project again in class on Monday. Lets just hope we get enough direction to get it completed by Thursday.
This past Friday was our exam in the class and I'm really annoyed... Not with the exam, or the format, but with myself for not being as prepared for it as I would have liked. This class for whatever reason has made me super competitive and I was really counting on making a high score on this exam to solidify my rank/standing in the course. So basically I spent WAY more time prepping for the software engineering exam (same day) as I did for this exam and now I really regret it. As I mentioned, the exam wasn't too difficult, nor did it cover material that was completely unexpected. I just wish I would have studied class structures a little better before the exam. The exam format was definitely an upgrade from previous years where we were asked to choose the correct output (multiple choice) after reviewing some code similar to our quizzes. This time the entire exam was like a giant test suite that you could put in a C++ file and actually compile and run. The idea was to code up some solutions to the methods the professor asked us to write and then write test cases for those methods. One of reasons why I like this new format is because even if you don't know how to code a solution, you could create test cases for it and gain some quick points. Furthermore the exam actually prepared you for a real life career choice. If you walked away from this exam with the majority of your points on the exam coming from writing test cases, then this may indicate that you are better suited for a Software Development Engineer in Test role rather than a Software Development Engineer role. Anyways, I learned my lesson and will definitely need to hop on studying for the next test WAY ahead of schedule to get as close to that A grade as possible.
Project:
Not happy about our next project at all. For starters, we only have one week to complete the project as the professor released the project just a few days before the exam. Given that I am in both classes, I had two exams to study for which meant having to prioritize the exams over the projects. As a result I began working on the new project on Saturday. After spending several hours trying to wrap my head around the code I realized the task of implementing the standard library version of deque would not be as easy as BigInteger. There seems to be far less direction on this project. Furthermore, the test suite was of no help. It contains only two test cases and provided no hints as to how to implement the deque. Given the time constraint of one week I expected there to at least be a solid set of test cases given to us. Regardless the professor has informed us that he will be going over the project again in class on Monday. Lets just hope we get enough direction to get it completed by Thursday.
Sunday, July 13, 2014
Week 5
Class:
This week was once again a short week since there was no class this past Friday due to final exams for first session classes. We continued to stress function templates and generics which were meant to assist us with the Big Integer project we were working on. I was very happy to see the professor give the class insight on setting up an eager cache within the multiplies_digits function and also give us a templated version of the power function. The BigInteger project was a great way to get exposed to objects and classes in C++ and I hope the trend continues as I am looking forward to learning more specifically about the object oriented qualities of C++ including class extension.
Project:
The BigInteger project turned out to be a big pain... But not for the same reasons it was for everyone else in class. Piazza was peppered with questions about implementation details and students hunting down mysterious bugs. Im happy to report that since my partner and I had started the project earlier, we had plenty of time to carefully optimize and think through every function and not run into serious bugs. For students that had embraced the idea of code first, test later, this week proved to be hell. The problem we had was that our code worked just fine... without any problems... just painfully slow. Wednesday night my partner and I toiled for many hours in the 3rd floor lab trying to wrap our heads around the karatsuba method which we felt would help us speed up our program. To our disappointment it was slowing us down even more. Luckily the professor had released the templated Power function which allowed us to bring our time down to within an acceptable time as per project requirements allowing us to ditch karatsuba. Even though we got the bonus points, I was really upset with the performance of our solution and stayed up till 3AM Thursday night after turning in the project. I reworked most of the project and produced an informative post in Piazza to guide other students that were stuck with the same problem. Its definitely a good read and explains how karatsuba should really be used to make things way faster.
This week was once again a short week since there was no class this past Friday due to final exams for first session classes. We continued to stress function templates and generics which were meant to assist us with the Big Integer project we were working on. I was very happy to see the professor give the class insight on setting up an eager cache within the multiplies_digits function and also give us a templated version of the power function. The BigInteger project was a great way to get exposed to objects and classes in C++ and I hope the trend continues as I am looking forward to learning more specifically about the object oriented qualities of C++ including class extension.
Project:
The BigInteger project turned out to be a big pain... But not for the same reasons it was for everyone else in class. Piazza was peppered with questions about implementation details and students hunting down mysterious bugs. Im happy to report that since my partner and I had started the project earlier, we had plenty of time to carefully optimize and think through every function and not run into serious bugs. For students that had embraced the idea of code first, test later, this week proved to be hell. The problem we had was that our code worked just fine... without any problems... just painfully slow. Wednesday night my partner and I toiled for many hours in the 3rd floor lab trying to wrap our heads around the karatsuba method which we felt would help us speed up our program. To our disappointment it was slowing us down even more. Luckily the professor had released the templated Power function which allowed us to bring our time down to within an acceptable time as per project requirements allowing us to ditch karatsuba. Even though we got the bonus points, I was really upset with the performance of our solution and stayed up till 3AM Thursday night after turning in the project. I reworked most of the project and produced an informative post in Piazza to guide other students that were stuck with the same problem. Its definitely a good read and explains how karatsuba should really be used to make things way faster.
Sunday, July 6, 2014
Week 4
Class:
This week was slightly more challenging. For starters, the professor revealed the latest project and spent a good amount of time explaining it on Monday. My concern is that this may have forced him to cover more material on Wednesday than consumable by the students. Usually every slide is designed to convey a few specific ideas in a well organized manner. This time the slides on Wednesday left a lot to digest. My assumption is that the long weekend and the need to explain the project may have eaten into the time required to drill in the concepts presented on Wednesday. I would have to say my single largest weakness with C++ is the organization of the files. In java its pretty straightforward: everything is an object, every object can have a main function, then there are interfaces blah blah blah... The point is that it doesn't usually matter where in the file functions are defined ie there isn't much order. This story changes in C++. The professor mentioned that since C++ uses a multipass compiler, it builds its understanding of the program over several passes and with each pass it learns something else. Im not quite sure I understand this and I hope the professor gets to spend some more time on it tomorrow.
Project:
The BigInteger project is pretty cool. It is very similar to the matrix project that is usually presented in the OOP class. The idea is to implement our own class from bottom to top. I didn't make the same mistake I made last time by starting late. This time I was quick to get a partner and hop to it. We were able to blow through some of the first functions with ease but the plus_digits and minus_digits required a little extra work. After some toiling on the white board we were able to put together some really efficient code while sticking to the original project parameters. Im glad we got a head start. My partner revealed that some of his friends haven't started yet and that they may be making a huge mistake underestimating the difficulty. My partner and I still need to swing by office hours tomorrow to figure out how to make some of the functions we have coded more generic. If you haven't started yet... good luck, its gonna be a long week.
This week was slightly more challenging. For starters, the professor revealed the latest project and spent a good amount of time explaining it on Monday. My concern is that this may have forced him to cover more material on Wednesday than consumable by the students. Usually every slide is designed to convey a few specific ideas in a well organized manner. This time the slides on Wednesday left a lot to digest. My assumption is that the long weekend and the need to explain the project may have eaten into the time required to drill in the concepts presented on Wednesday. I would have to say my single largest weakness with C++ is the organization of the files. In java its pretty straightforward: everything is an object, every object can have a main function, then there are interfaces blah blah blah... The point is that it doesn't usually matter where in the file functions are defined ie there isn't much order. This story changes in C++. The professor mentioned that since C++ uses a multipass compiler, it builds its understanding of the program over several passes and with each pass it learns something else. Im not quite sure I understand this and I hope the professor gets to spend some more time on it tomorrow.
Project:
The BigInteger project is pretty cool. It is very similar to the matrix project that is usually presented in the OOP class. The idea is to implement our own class from bottom to top. I didn't make the same mistake I made last time by starting late. This time I was quick to get a partner and hop to it. We were able to blow through some of the first functions with ease but the plus_digits and minus_digits required a little extra work. After some toiling on the white board we were able to put together some really efficient code while sticking to the original project parameters. Im glad we got a head start. My partner revealed that some of his friends haven't started yet and that they may be making a huge mistake underestimating the difficulty. My partner and I still need to swing by office hours tomorrow to figure out how to make some of the functions we have coded more generic. If you haven't started yet... good luck, its gonna be a long week.
Sunday, June 29, 2014
Week 3
Class:
This week was a bit more pleasant than the last, partly because I
remember a lot of it from object oriented programming from a while back. This
week we really got to see what separates C++ from the rest of the programming
languages and got an insight as to why its so damn fast. The key is passing by
reference. By simply passing the memory location of what you want the other
function to access you eliminate the need to copy large data structures. You
can also iterate over arrays of any type simply by iterating over the locations
in memory where the data is stored. As the week finished up we got to talk more
about how to prevent other developers from misusing this flexibility that C++
provides. By using special types of pointers to specially marked memory
locations we can limit the damage that can be done by accident or even by
malicious intent.
Project:
Australian Voting turned out to be more challenging than I had
anticipated. This was my own mistake. Having seen how easy Collatz was to
complete the day it was due, I underestimated Australian Voting drastically and
as a result I started very late since I was completely focused on Netflix. I
spent several hours trying to get the reading of the input and the formatting
of the output correct. I knew that this was a key part of the project. After
spending a bit of time modifying the skeleton code over from Collatz I quickly
focused on getting the input output tests to succeed without issues. As per the
requirements I then knocked out a non-cache version and passed all my tests.
However I was faced with a problem because UVa indicated a runtime error was at
play. All the tests that I had written were passing and so naturally I was
confused. Luckily some students had already posted acceptance tests. After running
several of them successfully I finally ran one that generated a cryptic error
in my program. I analyzed the particular election that had failed and added it
to my test suite. I was able to fix the bug and got UVa to accept my solution.
The only problem was that it was now 7:30PM on Thursday and I still needed to
generate acceptance tests and write a non-cache solution. Needless to say I
didn’t get the project in by the deadline. Several hours later I finished it
and was able to turn it in. Even though I lost 20 points on a project that
truly wasn’t much more difficult than Collatz, I learned a valuable lesson:
Don’t bother working to get bonus points for any project until AFTER you have
finished the minimum requirements for ALL of them. Lesson learned.
On to week 4 :)
Sunday, June 22, 2014
Week 2
Class:
This week was quite a bit more challenging than the last. C++ is a very tricky language and it appears that as a developer you can choose to override a lot different things that java doesn't even come close to allowing. For example, you can override the += operator to handle objects instead of just the built in types. As a result it becomes important to know exactly what kind of things you can put on either side of the operator as well as what the final operation returns. This happens to be the weakest part of my understanding as two bombed quizzes have revealed. I need to swing by office hours this week to get this l-value and r-value stuff clarified and understood as soon as possible. Im also very excited for the next topic since this last Friday the professor got to talking about memory management. People are usually TERRIFIED of this concept but lucky for me I had spent some time last semester looking at some cool videos online to prepare for some of my C++ interviews. For those of you who are coming from java and are completely lost when it comes to C++, I highly recommend watching these videos from Stanford University. The class (CS106B Programming Abstractions) was taught by Julie Zelenski way back in 2006 so a lot of the stuff she shows is from C99 but its still an excellent introduction to C++. Anyways, in this particular lecture, she does an excellent job of motivating the idea behind pointers and follows into the next lecture explaining some of the really important concepts that Professor Downing explained this past week.
Project:
Collatz was a pleasant success. I started working on it Monday at noon and was done by 8pmish. This is mostly due in part to the fact that I had spent much of the weekend doing this exact same project in python. The majority of the time goes into fulfilling the many requirements for the project but I don't actually mind them as I can practically see how some of them are useful. Wednesday went really well with the introduction to the Australian Voting Project. Seeing that I have a partner in the CS373 class and I need to be as available as possible for that project I decided to go it alone for this one as the difficulty does not look so bad. This project seems to make perfect sense even though a lot of other students seem to be a little lost on it. I am a little bummed that the only extra credit we can get on this project stems from being with a partner which means I'll have to be extra careful not to loose points anywhere. My other reason for going solo on this project is that I really want to make it a habit to follow the professors templates and recommended development cycle as closely as possible. Its usually the case that other seasoned programmers will be set in their own ways on how to develop code which usually means implementation before test code. I really want to avoid that.
This week was quite a bit more challenging than the last. C++ is a very tricky language and it appears that as a developer you can choose to override a lot different things that java doesn't even come close to allowing. For example, you can override the += operator to handle objects instead of just the built in types. As a result it becomes important to know exactly what kind of things you can put on either side of the operator as well as what the final operation returns. This happens to be the weakest part of my understanding as two bombed quizzes have revealed. I need to swing by office hours this week to get this l-value and r-value stuff clarified and understood as soon as possible. Im also very excited for the next topic since this last Friday the professor got to talking about memory management. People are usually TERRIFIED of this concept but lucky for me I had spent some time last semester looking at some cool videos online to prepare for some of my C++ interviews. For those of you who are coming from java and are completely lost when it comes to C++, I highly recommend watching these videos from Stanford University. The class (CS106B Programming Abstractions) was taught by Julie Zelenski way back in 2006 so a lot of the stuff she shows is from C99 but its still an excellent introduction to C++. Anyways, in this particular lecture, she does an excellent job of motivating the idea behind pointers and follows into the next lecture explaining some of the really important concepts that Professor Downing explained this past week.
Project:
Collatz was a pleasant success. I started working on it Monday at noon and was done by 8pmish. This is mostly due in part to the fact that I had spent much of the weekend doing this exact same project in python. The majority of the time goes into fulfilling the many requirements for the project but I don't actually mind them as I can practically see how some of them are useful. Wednesday went really well with the introduction to the Australian Voting Project. Seeing that I have a partner in the CS373 class and I need to be as available as possible for that project I decided to go it alone for this one as the difficulty does not look so bad. This project seems to make perfect sense even though a lot of other students seem to be a little lost on it. I am a little bummed that the only extra credit we can get on this project stems from being with a partner which means I'll have to be extra careful not to loose points anywhere. My other reason for going solo on this project is that I really want to make it a habit to follow the professors templates and recommended development cycle as closely as possible. Its usually the case that other seasoned programmers will be set in their own ways on how to develop code which usually means implementation before test code. I really want to avoid that.
Sunday, June 15, 2014
Week 1
Let me start off by sharing why I am taking this class. I need an upper division CS elective to graduate in two months. One might wonder why would I want to take this class over something easier (from what I have heard) like Computer Security or Data Management both of which are being offered over the summer. My reason for taking this class is as follows. Last year I realized that I wanted to become a developer in the finance industry. I wanted to make a program that would be able to analyze, pick, and trade stocks automatically. Before I could embark on a project like this I would need some experience so I began hunting down companies that specialize in this kind of work, writing software to manage portfolios, balance mutual funds, and even conducting high frequency trades on exchanges across the world. I soon realized that I was a Java programmer competing in a world where the speed and performance of C++ was sought after. This past March I was blessed with a job offer from FactSet Research Systems located here in Austin and I immediately accepted. While the code review part of the interview did not go well, and clearly revealed my deficiency to the managers in C++, I blew threw the algorithms part of the interview with flying colors. But before hiring me the managers had discussed with the team if they wanted me on board and some of them (being UT Alums) suggested that I would be a much more valuable asset if I took this particular class from Professor Downing. No doubt when I attempted and dropped Object Oriented Programming almost 2 years ago I knew that Professor Downing does an excellent job at teaching and even more so evaluating and testing our knowledge of the material. Moreover he focuses on making us much more employable rather than just good Graduate Student Applicants. Desperately needing the job, the ability to dominate C++, and the last CS class for graduation, it became obvious that taking this class was a no brainer.
Just in the first week the professor has already gone over the importance having a portfolio demonstrating our abilities and obtaining a good summer internship in order to become more employable. In particular the professor has introduced us to the importance of developing in a certain format which requires us to first write test code thus helping us as developers narrow our focus to write passing code that only passes those tests that we have already written. The added benefit of working under this kind of paradigm is that if and when we run into a bug, it is always easy to simply run our test cases quickly to find out what errors our new code produced thus substantially reducing our debug time. Over the course of the semester I look forward to seeing how SOLID principles are applied to the C++ language and more specifically the intricacies of the STL.
A word of advice to other students planning on taking this class. Print off the slides that the professor will go over the next day in class. He usually puts them up the night before the class. Bring these notes to class and take active notes. This ensures that you won't forget about the small details that the professor mentions when he goes through the slides since laptops are not allowed. This is very good advice coming from someone who has taken his exams before.
Subscribe to:
Posts (Atom)