vrnm

I like to put the public interface of classes before the private implementation details. For this reason I always use struct. It saves some typing and decent C++ programmers know the difference. You cannot enforce any of these extra semantic meanings in code, so I consider them to be a waste of time anyways.

In Germany you get around 2000-2500 netto per month for doing a PhD. Its like an entry level engineering salary, but instead of working for someone else, you are working for your self (on your own PhD, which is a lot of fun). Furthermore, you are still a student, so you get all the student benefits available (really cheap transportation, cheaper food, cheaper sports, travels...).

The problem you need to solve determines which algorithms you need to use and which data structures allow those algorithms to perform well. However, that's just whiteboard computer science.

Nowadays, performance depends almost exclusively on memory bandwidth usage and spatial and temporal memory locality, i.e. the only thing that matters is how much memory you are moving and how you are traversing it (the number of additions/divisions/branches doesn't matter that much).

In other words, your machine prefers data structures with good memory locality which determine which algorithms you can use and which problems are fast to solve. That is, in real life (as opposed to white board computer science) the order is inverted.

The question is: are you constrained at all by the machine? Because if you can solve the problems you want to solve without knowing about memory, then you obviously don't need to know about memory. On the other hand, if you are constrained by computing time, power consumption and so on, then you either learn about memory or can't solve your problem.

Again in other words, if you can get the job done in ruby/python/haskell/java/lisp... then do it! You'll do it faster, nicer, probably more maintainable... However, if you cannot get it done there, you'll need to use C++/C/Fortran/D...