Re: C23 thoughts and opinions

On 03/06/2024 18:50, Scott Lurndal wrote:

David Brown <david.brown@hesbynett.no> writes:

On 03/06/2024 11:00, Michael S wrote:

On Sun, 2 Jun 2024 21:44:01 +0200
David Brown <david.brown@hesbynett.no> wrote:

Oh, there's little doubt that most publicly available RTOS kernels are
in C, not C++.  That does not mean C is in any way /better/ for the
task.  There are multiple reasons for C being the language of choice here:
>
1. Most well-known RTOS kernels have a history stretching back to the
previous century.  C++ was not nearly as viable an option at that time,
for a great many reasons.

 I would disagree with this.   The Chorus microkernel (Chorus Systemes,
later purchased by Sun) was started in the late 1980's and was
written in C++ (with a small set of assembler functions).  This was
using Cfront (2.1 and later 3.0).   I'm pretty sure it is still in
use.  This was long before templates, exceptions or the standard library.
 

C++ was viable for the kind of systems you were working with (clearly that is true, since you worked on an OS written in C++ at that time).
I have been specifically referring to "well-known" RTOS's - the sort that would have a Wikipedia page, or whose name has a chance of being recognised by many embedded programmers.  (I realise this is a very vague and subjective classification.)  I am quite confident that the majority of RTOS's ever written are proprietary, with little if any public information.  Some of these will be written in C, others in Assembly, C++, Ada, and perhaps other languages.  I think the share of C++ in these will be a lot higher than in more commonly used RTOS's, because the team involved in developing and using them will be smaller and more controlled, negating many of the reasons for using C.

>
2. If you write your kernel in C++, you pretty much have to use C++ for
the application code unless you also write a C API for it.

 Clearly one can use C interfaces from C++ code.  And one can develop
C++ wrapper around C-type functionality.
 Our C++ kernels supported standard unix-style APIs between user
mode software and the kernel.
 

If you write
your kernel in C, you can use almost any language for the application code.

 If you write your kernel in _any_ lanaguage, you can use _any_ language
for the application code, or the kernel isn't much use to anyone.
 

Many - I think most - RTOS's are linked as libraries, rather than separately linked applications.