Thinking back on last weeks sudoku solver, a headache arises from the depths of my guts, as it was a painful act to start programming in a language that "you sort of know", but you actually don't. Its so similar to Java, and yet, its quite different. We all programmed the sudoku solver, and yet we all bs'd our way through it in our own individual styles. The functionality is the same naturally, but the attempts of breaking c++ were all quite different. Part one did not vary too much, as we all based our work on the file input of the game of life example. Part two however, varied.
There were brute force attempts and inefficient brute force attempts, to which I must count my own code.
There was the efficient Jekabs-Duncan style, and the lets-see-who-breaks-first Ron style. Rihards was somewhere in between. The naming of the code style should hopefully give away the robustness of the codes. If mine was a house, it would have followed the chaos theory and collapsed at the mere sight of a butterfly. It was quite instabil, and only seldom "wanted" to solve the sudoku, and only if no butterfly's were present.
The problem causation is my lack of planning and the consequently bad structure which leads to something that's overly complicated and can neither be fixed nor read - ever again. It all makes sense once I see someone else's code, but up until then, my brain is convinced that that's the way to go.
Now that I look back, I would structure the program much differently, or so to say, I would give it a structure at all. It would take me a quarter of the time and might actually work.

This past week, we looked at strings, vectors and hash tables.
The strings were surprisingly the same as in Java. I, as a programmer, never used too many functions from the String class but always the same ones. That's why I cant too precisely say what the similarities are between the Java functions and the c++ functions, but what I can say about the ones I use, they are all present and syntactically the same or very similar.
I think the "find_first_of" and so on, methods quite handy, and should I ever have to program a search for words or text in a text, I will know instantly which functions to take. I don't know who came up with those, but I like the geeky flair that lies around them, such as saying: take us, we are commands with one purpose, you know you want to.
The String stream library is a function that is bound to be useful one day. As soon as any file or input will ever be processed, that will come in handy and be irreplaceable.
This week we also talked about classes and objects in c++, and of course their relation to classes and objects in object oriented Java. To this, I can only say that, in Java we got introduced to classes very well, and getting the concept of classes and objects in c++ was an automated process. The only difference is that c++ needs to know of the existence of a method or class before its called the first time. In fact, now that I look at Java again, I wonder why the Java compiler copes with that at all. It makes sense to "tell" the program what it has in store, and I have no difficulty getting my head around that concept.
The next big thing we handled this week was the hash table. While I was aware that hash tables existed, until now, I never took care to learn how they work. The concept of the hash table is quite easy and I think its a handy way to organise data along a self chosen scope. Getting the key function right could probably become a pain at times, but in general this seems like something I might use one day when there is a lot of data to organise into some filing system. When I say that I might use it one day, I admit that the whole time, I was speaking of a linked or chained hash table. I don't actually get the purpose of a simple hash table, also because I think it should be called a hash array. I'm excited to start programming on the task for this course, which is to create a chained hash table. Maybe my scum-bag-brain will even have the courtesy of allowing me to plan the program before starting to fill the screen with bs. Enough of the cursing now, on to the next topic:
We also looked at vectors. Now that's something I can do in my sleep, if I didn't kill dreams like that instantly. Vectors are arrays, the initialisation is a bit simpler as in Java, as you don't have to actually create an object of the class array first, but otherwise its the same thing. I would always rather use an array than a chained hash table if I don't have loads of data, but it depends on the situation and especially the potential of growth that will help make the decision. The point is, if you don't have loads of data, or the data cannot efficiently be separated into categories for the hash table, you could end up having a hash table with very long arrays or vectors in each entry, which is not going to be effective.

In our other two courses, we went into more detail in Bash scripting and time complexities of code. The bash scripting seems like a creature we're awaking, that should rather be sleeping. It seems to be a very powerful programming language, but compared to the relatively-close-to-English Java or c++, bash is a pain handling with symbols and commands. Bash appears to me to be a programming language designed by lazy programming beasts. They found it unworthy to write a single word out, as they could easily remember the abbreviation, and now we're stuck with one letter commands. The time complexity calculation remains to be an issue of confusion, and stepping through code for hours seems rather like a punishment than being taught. A new approach would be highly appreciated, not another 3-hour marathon stepping through programs using non-logical tables on unreadable whiteboards explained with far-too-easy questions to those that are still awake. Other than that, we're all set. I can see how using bash scripting, we could easily call c++ scripts and so do quite powerful things. We would then eventually be able to write our own system applications and viruses, not that we wanted, but we could.