OSDev.org

Some random thoughts on the subject:

People are sortof forgetting their own individual taste for style. Some people prefer thinking in objects, communication and top-down approaches, while some prefer writing small stubs expected to become part of a larger whole, and it is this preference that should be an important part in the C/C++ decision.

After all, you can do in C++ what you can do in C, and vice versa. (expects the horrible difficulty argument here)

And although i dont want to favour one language over the other, I know somebody that "said" he was a c++ programmer. Pretty sad story to be honest, but i think its good to know.
He always complained about the same thing: after getting past about ~50 lines his code started to randomly generate segmentation faults and other unexpected behaviour, and he seemed to be completely unable to trace it. In the end it always came out that he had been messing with pointers in some way, so that his objects were either wiped, lost or somewhere you wouldnt want them.
Since he couldnt seem to figure what he was actually doing, i tried to tell him to use a less forgiving language so that he could learn whatever was happening, as well as some system architecture. So i told him that he should do his next few attempts in C (for being C++ minus the things he kept messing up) in the hope he would figure what was going on, but he refused.
In the end he became so frustrated that he quit programming altogether.

The point here is that higher languages might be easier, they sometimes attempt to hide the mechanisms of the underlying system. So for those wanting to program C++, you should know very good what it does between two lines of code. (same goes for every language, but since C is pretty close to the hardware, C++ is a big step in comparison)

In summary, both languages will do, but you must be able to properly operate whichever one you choose.
That IMHO is also the main reason for the "C for OSes" thinking, since its less difficult to know the likes of C than of C++

Ok, no more argument from me (we'd only be saying the same things over and over anyway, which gets boring).

Combuster:
If he was programming in userland in C++ then there's usually almost no reason to be playing with pointers (except if you're optimising something that needs to be as fast as it can, but your description of him didn't strike me as the kind of guy who'd be doing that yet). When he said he was a "C++" programmer did he actually mean he was a "C with classes" programmer? Of course, if he was doing something low-level then obviously he'll have the need sometimes.

Kemp wrote:Combuster:
If he was programming in userland in C++ then there's usually almost no reason to be playing with pointers (except if you're optimising something that needs to be as fast as it can, but your description of him didn't strike me as the kind of guy who'd be doing that yet). When he said he was a "C++" programmer did he actually mean he was a "C with classes" programmer? Of course, if he was doing something low-level then obviously he'll have the need sometimes.

The point was, he used pointers close to randomly, mixing then up with classes and the like, adding random *s in variable definitions. That sort of things. He probably saw some code doing that so he copied it over without knowing what it does. I mean, seeing things like " MyClass **mc; " being the standard attempt to satisfy the type checker gives me the creeps...

I assumed when I was reading your post that he actually knew what he was doing but just had some minor misconceptions. Maybe you should keep a copy of his work and submit it to TheDailyWTF ;D


Edit for clarity

Combuster.. You said you would not tell anyone about that! >:(

I was so close to making it work anyway, the copy and paste only produced a couple of segmentation faults..