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...

Imagine how pissed Linus is going to be when he hears about Java.

==EDIT==
A good (short) read. (Linus ranting off his rocker)
http://thread.gmane....643/focus=57918

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.

There's no reason to use C over C++, even in embedded systems, except for legacy support. All compilers that target embedded systems allow you to turn off exceptions and RTTI, etc. If you don't use a feature, you don't pay for it. But there's no reason to use C and paint yourself in a corner if you end up needing a feature found in C++ that C doesn't have.


This perspective is coming from someone who does embedded development for a living. I've worked with DSPs (TI C64x+), microprocessors (MSP430), and FPGA softcores (Xilinx MicroBlaze) all within the past 3 months. Guess what? All of the applications were written in C++. Even on the MSP430 that ran at 16MHz and had 4kBytes of RAM.

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++).

Imagine how pissed Linus is going to be when he hears about Java.

==EDIT==
A good (short) read. (Linus ranting off his rocker)
http://thread.gmane....643/focus=57918

Haha that post is funny and very arrogant even for Linus. This is actually because you quoted the wrong post. If you actually read his other posts they are more sane and less of a rant.
Either way Linus is a very smart man, however, his opinions should be taken with a grain of salt because they are borderline insane. The better post from that whole exchange is this one.
More Sane reply. But really please lets not use Linus as a definition of a good read especially if he is ranting.


I also agree with Hodgman above. As I stated it is not that C++ can't be used for low level tasks it is just that C is better for certain low level tasks. For instance on an android or ios device ASM and C are used to bootstrap the operating systems and in androids case it's virtual machine (which I believe is also written in C). But the rest of android is a custom Java byte compile and in IOS the typical language is Objective-C which is literally an extension on top of C unlike C++ which is more of it's own beast at this point. In the future it also looks like the guys at apple are going to move people towards using Ruby instead anyway due to the massive Ruby -> objective C compiler they are working on.
The point is C is good for some tasks, Java for others, and C++ for some more. So people need to stop dwelling on this stuff and just use what they want to use.
A language is nothing more then a tool for a job people need to stop arguing what is better.

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.

...

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.

Nowadays, I do a lot of embedded systems work, mostly on the PIC24 line of 16bit microcontrollers and I use a mix of C and assembly. While I'm certain that for a lot of people your points are true, they certainly do not aply to everyone: the reason I use C over C++ is not for any of the reasons you gave (except perhaps the C compilers are easier to implement, in an indirect way), but rather that of availability. There are good C compilers available for PIC24's, but I have yet to find a good C++ compiler (or any other langauge I know). If there was a good C++ compiler, I would use that instead. The lack of availability of other language compilers could be down to a number of reasons including historical reasons and the fact that C compilers are easier to implement.

This doesn't invalidate what you said at all, but rather brings up another reason: availability.

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.