why is C++ not commonly used in low level code?

For embedded devices, one of the biggest reasons is size/simplicity. I don't mean developer simplicity, I mean runtime simplicity. WIth ulta constrained resources, implementing the C runtime is a lot "lighter". Also, frankly, C is far simpiler to implement, just compare the size of the language specs.



As to why it's not used in Linux, thats cause Linus doesn't like C++.

It has a tendency to be a little less predictable in things like memory allocations, object sizes and what it's copying where.

People who are working (say) inside the Linux kernel need that little bit extra control over exactly what's happening.

First, let's get our terms correct. There is only one "low level" language: assembly. The reason this isn't widely used in application development should be clear by simply looking at some example code. I am a fan of Assymbly, but I realize that it is impractical for application development.

C is a mid-level language that is capable of compiling to as near to the size and execution speed of an Assembly executable as possible with non-low-level coding. On a system level, the object orientation of C++ is just a naming trick, but it does allow more abstraction in source. More abstraction means more reliance on libraries and language than the compiler. This means that an amount of the binary included in the executable is completely unnecessary. Now, before people get their hackles up of this, let me explain: if a function included in a program was written to handle dozens of different situations and you only ever use that function for a single situation, you have un-used code and a procedure that is more broad in scope and size than you actually need.

The modern idea is that memory is cheap and processors are fast. Linux does not, by and large, abide by this idea. Thus I refer to the posts above mine by Katie.

Correct the main reason certain things are coded in C instead of C++ is for that fine grained control over computationally expensive tasks as well as to limit memory footprints. Some examples of these are embeded devices, kernel's for an OS, and even 90% of the Version control systems people use everyday. An example of a VCS written in C++ is monotone. If you take Monotone and compare it to say mercurial you will notices mercurial blows monotone out of the water in speed and efficiency and it is easier to maintain. For those that don't know the core of mercurial is actually coded in C the python interacts with the parts of the core that are in C. Certain things are also easier to express and maintain in a language like C as well. I would hate to look at the linux kernel if it was written in C++ and used OOP it would be a maintenance nightmare.

The ultimate point here is that each language is good at certain tasks. I am currently using C for my project because it is the proper tool for the job and I happen to really like the language and I am very comfortable in using it. If I was making a game I would use C++ or some other language because those languages cater better for that type of programming. Learn to be flexible don't worry why something is not used. If it is not used it comes down to 2 simple answers 1. it was not right for the job or 2 the main developer is more comfortable with said language.

To the OP also check out my latest blog post it actually develops an algorithm in C++ and then C and explains why the C is actually more efficient.

Edit: Note C is very tiny and easy to port to different architectures. The runtime is exceptionally smaller then the C++ runtime as well. C is always ported first to a new architecture because you technically can't port C++ until C is ported over. Sure C++ has great features but with those features come overhead that can't be present under certain circumstances.

Just as a side note, it seems these days that C++ is starting to be the "low level" you are referring to, since most things are moving towards higher level managed languages and frameworks. Game development is one of the few cases in which this trend was somehow restrained but more and more developers and studios move towards game development tools / engines (Unity, Shiva), .NET, Java, etc. From my personal point of view development speed and maintainability surpasses the performance of lower level languages (not to be confused with application performance).

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.

C typically has much less overhead than C++. In environments and applications where memory and CPU are scarce, or need to be used extremely efficiently, C tends to be used more.
There are other reasons though. The people who work on these systems are used to C, most of the existing code is already written in C, and interfacing or re-writing isn't worth the money and effort, as well as certain stigmas associated with "higher level" languages. C++ compilers weren't very good for a while, that sort of thing.

For all its faults, C is actually a very nice language, it just lacks some of the bells and whistles that newer languages have. There were computers, video games, and great applications long before Java and C# became popular, and they were pretty much all built on C.

C typically has much less overhead than C++.

People keep saying this in this thread. Could we have some examples of some C++ "overhead" that outweighs having to replicate the same required behaviour in a C program?

RTTI can be turned off if not required. The overhead of exception handling is typically outweighed by the additional code needed to handle errors in a C program. Inheritance overheads are typically outweighed by similar. A C++ class with methods and members (and no virtual methods or inheritance) is a C struct and some functions by the time it's been compiled and linked.

Usual proviso applies about assuming a decent C++ compiler for a given platform, as already discussed above.

One of the central design principles of C++ is "don't pay for what you don't use", so I don't know what you are all on about "C++ overhead". C++ programmers are very adamant to the language committee that we don't want features to impact performance if they aren't used.

C++ *is* commonly used in "low level" code, and you can write operating systems with C++ just as you can with C.

Comparing a popular version control system with an unpopular one and claiming the performance difference is due to using a C++ compiler vs a C compiler is just silly.

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.