Home/ Questions/Q 8433117
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-10T06:18:00+00:00

The question is NOT about the Linux kernel. It is NOT a C vs.

  • 0

The question is NOT about the Linux kernel. It is NOT a C vs. C++ debate either.

I did a research and it seems to me that C++ lacks tool support when it comes to exception handling and memory allocation for embedded systems:

Why is the linux kernel not implemented in C++?
Beside the accepted answer see also Ben Collins’ answer.

Linus Torvalds on C++:

“[…] anybody who designs his kernel modules for C++ is […]
(b) a C++ bigot that can’t see what he is writing is really just C anyway”

” – the whole C++ exception handling thing is fundamentally broken. It’s especially broken for kernels.
– any compiler or language that likes to hide things like memory allocations behind your back just isn’t a good choice for a kernel.”

JOINT STRIKE FIGHTER AIR VEHICLE C++ CODING STANDARDS:

“AV Rule 208 C++ exceptions shall not be used”

  1. Are the exception handling and the memory allocation the only points where C++ apparently lacks tool support (in this context)?

  2. To fix the exception handling issue, one has to provide bound on the time till the exception is caught after it is thrown?

  3. Could you please explain me why the memory allocation is an issue? How can one overcome this issue, what has to be done?

As I see this, in both cases one has to provide an upper bound at compile time on something nontrivial that happens and depends on things at run-time.

Answer:

  1. No, dynamic casts were also an issue but it has been solved.

  2. Basically yes. The time needed to handle exceptions has to be bounded by analyzing all the throw paths.

  3. See solution on slides “How to live without new” in Embedded systems programming. In short: pre-allocate (global objects, stacks, pools).

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Well, there are a couple of things. First, you have to remember that the STL is completely built on OS routines, the C standard library, and dynamic allocation. When your writing a kernel, there is no dynamic memory allocation for you (you’re providing it) there is no C standard library (you have to provide one built on top of your kernel), and you are providing system calls. Then there is the fact that C interops very well and easily with assembly, whereas C++ is very difficult to interface with assembly because the ABI isn’t necessarily constant, nor are names. Because of name mangling, you get a whole new level of complication.

    Then, you have to remember that when you are building an OS, you need to know and control every aspect of the memory used by the kernel. In C++, there are quite a few hidden structures that you have no control over (vtables, RTTI, exceptions) that would severely interfere with your work.

    In other words, what Linus is saying is that with C, you can easily understand the assembly being generated and it is simple enough to run directly on the machine. Although C++ can, you will always have to set up quite a bit of context and still do some C to interface the assembly and C. Another reason is that in systems programing, you need to know exactly how methods are being called. C has the very well documented C calling conventions, but in C++ you have this to deal with, name mangling, etc.

    In short, it’s because C++ does things without you asking.

    Per @Josh’s comment bellow, another thing C++ does behind your back is constructors and destructors. They add overhead to enter and exiting stack frames, and most of all, make assembly interop even harder, as when you destroy a C++ stack frame, you have to call the destructor of every object in it. This gets ugly quickly.

    • 0