Wow. Lots of misinformation here.


The truth of the matter is virtually entirely historical. C was stable and well-understood many years before C++, and enjoyed a lot of widespread usage in the Unix world in particular. C was entrenched before C++ was even invented; given that it took a couple of decades for C++ to become a language that was worth writing an OS (or whatever) in, it shouldn't be surprising at all that C remained king for that period. C++ has only very recently (i.e. since 2003 or so) had good enough specifications and tools to actually be competitive with C in the truly low-level space, because low-level stuff requires hitting corner cases of the C++ language that most applications never have to worry about. In essence, C++ wasn't ready for prime time until a few years ago as far as extremely efficient low-level code is concerned.


Now, given that, it should be obvious why C is still only slowly being supplanted: because C had decades to take root. Porting code is fucking expensive and difficult, especially when you're talking about, oh, say, an OS kernel. It's a no-brainer to retain a well-refined language like C over switching to C++ and risking a huge code rewrite and possibly running into areas where the tools are still weak. This is especially true on hardware where C++ compilers are still archaic and half-broken.

By historical accident, some people (like Linus Torvalds) became incomprehensibly, irrationally opposed to using C++ ever, and so even fewer people have an interest in bucking the trend and switching away from C.

Of course, by now, if you want to invest the effort to get away from C, then there's far better options out there than the shit-show that is C++. Consider projects like Singularity that aim to use much better languages for OS implementation, for instance.

Wow. Lots of misinformation here.


The truth of the matter is virtually entirely historical. C was stable and well-understood many years before C++, and enjoyed a lot of widespread usage in the Unix world in particular. C was entrenched before C++ was even invented; given that it took a couple of decades for C++ to become a language that was worth writing an OS (or whatever) in, it shouldn't be surprising at all that C remained king for that period. C++ has only very recently (i.e. since 2003 or so) had good enough specifications and tools to actually be competitive with C in the truly low-level space, because low-level stuff requires hitting corner cases of the C++ language that most applications never have to worry about. In essence, C++ wasn't ready for prime time until a few years ago as far as extremely efficient low-level code is concerned.


Now, given that, it should be obvious why C is still only slowly being supplanted: because C had decades to take root. Porting code is fucking expensive and difficult, especially when you're talking about, oh, say, an OS kernel. It's a no-brainer to retain a well-refined language like C over switching to C++ and risking a huge code rewrite and possibly running into areas where the tools are still weak. This is especially true on hardware where C++ compilers are still archaic and half-broken.

By historical accident, some people (like Linus Torvalds) became incomprehensibly, irrationally opposed to using C++ ever, and so even fewer people have an interest in bucking the trend and switching away from C.

Of course, by now, if you want to invest the effort to get away from C, then there's far better options out there than the shit-show that is C++. Consider projects like Singularity that aim to use much better languages for OS implementation, for instance.

Say what you will, everything I said is still fact:


1- C is used in embedded systems because it is ( as a system ) small and easier to implement, and has a lesser footprint, especially when you are talking megabytes of available RAM.

2- C is not used in Linux because Linus hates it.



No misinformation in either regard.



I have worked, and have friends that continue to work on embedded systems, and C is still the reigning champ. This is because implementing C ( and it's tool chain ) is a hell of a lot easier than C++, and has a smaller footprint, while at the same time, the code complexity of embeded systems is generally quite small, so what C++ brings to the table really isn't required. Small-C is probably as guilty for the continued success of C in embeded systems as any other factor, as it was the learning basis for so many people regarding compiler development.

Why so defensive? I obviously didn't contradict or attempt to dispute anything you said, and I never claimed I was addressing you anyways...

why is C++ not commonly used in low level code?[sup][citation needed][/sup][/quote]This whole thread is based on a large assumption...
As mentioned above, this assumption is true for the Linux kernel. However, it's not true for many other areas.

The vast majority of game middleware systems that I've worked with (which are all very "low-level code") have been written in C++ (albeit usually not in the ivory-tower OOP style associated with typical C++).

Meh. There is no real reason that any given compilable language should result in different final executable code than any other. The features of C++ that add to the generated code should optional and either only included if used or removable with compiler switches. However, this does not automatically mean that such an "ideal" compiler exists for a given platform.

Everything C++ does with memory is entirely predictable in the hands of someone who understands the language. Anything C++ does automatically behind the scenes that you actually need would just have to be manually implemented in C, say. Oh teh noes, templates cause code bloat, far better than I should manually write three versions of the same function. Etc etc.

C is older, more compilers exist, more low-level-domain programmers learned that way. I suspect that if it is indeed more commonly used for "low-level" programming, whatever that may mean, it is more a cultural than technological choice or due to availability of battle-tested compilers for a given platform.

That's pretty much the truth, the whole truth, and nothing but the truth, right there. Absolutely couldn't agree more!

FYI: At the place I work, embedded programming is approximately 10% asm, 40% C and 50% C++

Yes technically there are few reasons why C++ code should become a bigger binary compared to C code. For the most part, C++ degrades to a procedural program at the lowest level anyway. Methods become procedures that pass around the this pointer of a class in a similar way as you'd pass around a struct pointer in C. As for virtual methods and polymorphism, they are a collection function pointers, which is nothing overly exotic in C land either. I suppose one big overhead in C++ is probably exception handling. Exceptions are generally considered expensive on embedded devices, but you can avoid using exceptions if when required. I also have to agree with dublindan, choice comes often down to the quality of the tools for your chosen embedded platform, and C often wins in that respect.