One thing I've wondered about is why C is so much more common than C++ in low level code. Even without exceptions and RTTI, C++ as a lot of useful features, and it is nearly a complete superset of C as well. The only explanation I can think of is the lack of name mangling and desire for simplicity. However, this is kind of defeated by relying on complicated macro tricks which just imitate C++ features in a less readable way.

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.