Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Mon, 3 Jun 2024 21:05:17 +0200
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <v3l45d$pp8$1@dont-email.me>
References: <v2l828$18v7f$1@dont-email.me>
 <beffc569-3606-b627-ded9-93ce8478f2dd@please.ty>
 <v2qfi0$2de9j$1@raubtier-asyl.eternal-september.org>
 <v2unfe$3alds$1@dont-email.me>
 <v2v637$3cunk$1@raubtier-asyl.eternal-september.org>
 <v3dmq6$2edto$1@dont-email.me> <hOu6O.6223$xPJ1.1866@fx09.iad>
 <20240602110213.00003b25@yahoo.com> <v3hn2j$3bdjn$1@dont-email.me>
 <20240602162914.0000648c@yahoo.com> <v3ii22$3g9ch$1@dont-email.me>
 <20240603120043.00003511@yahoo.com> <v3kra8$3vgef$1@dont-email.me>
 <Kvm7O.5231$Ktt5.2929@fx40.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 03 Jun 2024 21:05:17 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c10afcab4eb1583f2400c6e724b93904";
	logging-data="26408"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18inLf8VsI8Y0QNb3A91wAfRdQ7fdWfbzI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:k9NJOET+UVIJkQCQp5yhPcHnIo8=
In-Reply-To: <Kvm7O.5231$Ktt5.2929@fx40.iad>
Content-Language: en-GB
Bytes: 4085

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.