Should we use C++ for kernel implementation? about mimiker HOT 4 CLOSED

The way I see it this choice mostly depends on the desired project scale.

What exactly are the advantages of C++ over plain C, that make sense at kernel level?

The nice advantages of C++:

• Classes over structures, inheritance, virtual functions, interfaces, polymorphism.
  • This one requires no runtime support, so we'd get this for free. This may hopefully lead to some (nice?) OOP, provided we spend enough effort carefully designing interfaces. Polymorphism might be useful as well, especially in places where we would like to separate implementation from interface, so eg. hardware drivers
  • Most of such features can be simulated in C (function pointers in structures, conversion procedures), so this advantage is mostly the same as the following one.
• More elegant language-level syntax.
  • I guess this one is clear: C++ has con/destructors, automatic virtual calls, type conversions, operator overloading and a lot of goodies which are not really anything that was not achievable in C, but make the code so much nicer to read.
• STL (at least data structures).
  • Requires porting, which means extra effort before we would start actual work, but provides probably all data structures we might ever need.
  • Note that writing basic data structures in C is not that much effort as it may seem like, and the complex ones (if needed) can be borrowed from existing implementations.

The not-so-nice advantages:

• Memory management.
  • new/delete require runtime support, which may boil down to malloc/free, so not really an advantage over C. Requires careful use before paging and memory management is ready.
• Exception support.
  • Exceptions require runtime support, and therefore are not usable ootb. Furthermore, I have a hunch that the use of exceptions mixed with context switching and interrupts may create a lot of confusion, and end up being a hassle instead of an advantage. However, it's easy to force the compiler to completely disable exceptions.
• RTTI (typeid, dynamic_cast)
  • Requires runtime support. Can be easily disabled. In most cases, use of RTTI is avoidable, e.g. by implementing type info within classes that require it, and then restricting casts to static_ and reinterpret_.
• Global constructors.
  • I'm not sure whether these are that much helpful, but the osdev wiki assumes they are. These obviously require runtime support and manual initialisation.

Possible disadvantages:

• Sticking to one particular C++ ABI.
  • It may be not important, it's not like we have a ton of toolchains to choose from, anyway.

I believe we need to consider whether these advantages are really worth the effort of setting them up. Using C++ seems like a longer-term investment, it requires a lot of work to prepare, but may result in more elegant source, which will be desired if we aim to develop a serious kernel.

If what we do is just an experiment, and do not expect to develop a large system, I'd vote for sticking to plain C, because it's simpler, has less setup overhead, and is probably less confusing (especially for debugging).

TL;DR: I suspect that the advantages of C++ will only pay off in a large kernel.

from mimiker.

I think you are missing the point here. It is quite clear that the only sane way to enable C++ in kernel is to rely on the language implementation (i.e. the compiler and the appropriate libraries), so the real question is what it would take to be able to link libstdc++ against the kernel. Well, it depends on C standard library and some additional target-specific functions, in case of Linux target that would be posix and some gnu extensions. Standard C library will be needed anyway and most of the remaining functions can be stubbed and their implementation deferred, indefinitely in some cases. In general I wouldn't expect much difficulties in porting the runtime C++ support, the most complicated probably will be configuring GCC target but that can be cheated by using an existing one.

As for C vs. C++ I won't list the differences here, anyone claiming to know both should know them, besides the most important ones were already mentioned (well, apart from templates and all the magic related to them, lambdas and non-container parts of the standard library). Unfortunately, standard C++ containers are non-intrusive what makes std::list, std::map and std::set useless in many cases. There is boost.intrusive, though.

Undoubtedly, apart from the language constructs and idioms (RAII!) that make it harder to introduce bugs iand speed up the development another big reason for using C++ is the fact that in some kernel subsystems (namely vfs and device management) using OOP at least to some extent is the most natural choice and because of that kernels like Linux or FreeBSD ended up with object-oriented C which, frankly, isn't very pretty.

However, there is a problem of code size. The board has only a tiny amount of flash and adding runtime support for C++ wouldn't exactly go well with the policy of using as little memory as possible. Exceptions are probably the biggest issue apart from requiring several stack unwinding procedures there is also dwarf information needed to perform the unwinding itself. I am not sure what the numbers here are (especially on MIPS) but it is definitely worth checking before deciding to use C++. On the other hand, I guess that before the flash size starts to become a problem the board will be already obsoleted by a newer model with more space for the kernel code.

There is also a compiler flag to disable exceptions, but I believe that it is an extremely bad idea to use it. The language, especially the standard library, weren't designed to be used without exceptions (e.g. without exceptions constructors cannot fail). For instance consider the following code:

void function(const std::vector<int>& vector) {
    auto copy(vector);
    // ...
}

What happens if the copy fails?

from mimiker.

MIPS ABI are listed in here. The toolchain uses o32 MIPS ABI and contains libstdc++. Hence it'd be nice to test if c++ compiler is fully functional.

from mimiker.

Let's finish this topic by saying that C++ enables a programmer to construct asbtractions too easily and as such doesn't encourage minimal designs. Many people in unix community view C++ as a bloated language with too many things to worry about. Even if we chose C++ over C it'd be a very strict subset without STL obviously. I won't argue right now... we've already gone too far to change our mind easily.

In your free time please muse on http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918 and corresponding chapter from "The Art of Unix Programming" http://www.catb.org/esr/writings/taoup/html/ch14s04.html#cc_language

from mimiker.