Re: C23 thoughts and opinions

On Sun, 2 Jun 2024 14:03:30 +0200
David Brown <david.brown@hesbynett.no> wrote:

On 02/06/2024 10:02, Michael S wrote:

On Sat, 01 Jun 2024 01:27:41 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
 

Lynn McGuire <lynnmcguire5@gmail.com> writes: 

On 5/26/2024 6:23 AM, Bonita Montero wrote: 

Am 26.05.2024 um 09:13 schrieb jak:
    

About this I only agree partially because it depends a lot on
the context in which it is used. Moreover, I would not know how
to indicate an optimal programming language for all seasons. 

>
C++ is in almost any case the better C.
    

What you describe is the greatest inconvenience of c++. To make
only one example, when they decided to rewrite the FB platform
to accelerate it, they thought of migrating from php to c++ and
they had a collapse of the staff suitable for work, so they
thought of relying a compiler that translated the php into c++
and many of the new languages were born to try to remedy hits
complexity. 

>
C++ is the wrong language for web applications.
I like Java more for that. 

>
C++ is the wrong language for real time apps. 

>
That's an incorrect statement.
 

No memory allocation allowed. 

>
It is trivially easy to write C++ code that doesn't
allocate memory dynamically.
 

>
I use C++ for my server side apps on my webserver.  Works great. 

>
I use C++ for operating systems (you can't get more real-time
than that) 

 
Engines control is FAR more real-time that OS, to list just one
example out of many. 

 
Most engine control software runs on an RTOS - so you have at least
as tough real-time requirements for the OS as for the application.

From what I read about this stuff (admittedly, long time ago) even
when there is a RTOS, the important part runs alongside RTOS rather than
"on" RTOS.
I.e. there is high priority interrupt that is never ever masked by OS in
the region that is anywhere close to expected time and all
time-sensitive work is done by ISR, with no sort of RTOS calls.

The OS stuff Scott works with, AFAIK, is real-time OS's for specific
tasks such as high-end network equipment.  It is not general-purpose
or desktop OS's (which I agree are not particularly real-time).

I'd characterized the software running within high-end NIC is as very
soft real-time. You only care for buffers to not overflow. And if they
overflow, it's not too bad either. The flow is very much unidirectional
or bi-directional with direction almost independent of each other.
There are dependencies between directions, e.g. TCP acks, but they a
weak dependencies timing-wise.
Hard real time is about closed loops, most often closed control loops,
but not only those.

 

Of course, nowadays most of these things are no longer done on
general-purpose CPUs or even MCUs.
 

 
I think you have got that backwards.
 
Most engine control /is/ done with general purpose microcontrollers,
or at least specific variants of them.  They will use ARM Cortex-R or
Cortex-M cores rather than Cortex-A cores (i.e., the "real-time"
cores or "microcontroller" cores rather than the "application" cores
you see in telephones, Macs, and ARM servers), but they are standard
cores. Another common choice is the PowerPC cores used in NXP's
engine controllers.
 
It used to be the case that engine control and other critical hard
real-time work was done with DSPs or FPGAs, but those days are long
past.
>

Are you sure?
It's much simpler and far more reliable to do such task with $5 PLD
(which today means FPGA that boots from internal flash, rather than
old day's PLD) than with MCU, regardless of price of MCU.
Even if MCU is $4.99 cheaper, the difference is a noise relatively to
price of engine.

 

and bare-metal hypervisors. 

 
It is hard to believe that you don't have at least one co-worker
that is begging to switch all new development to C approximately
every week. And couple of folks that beg for Rust.
 

 
It's possible that he has newbies amongst his co-workers, yes.
 

Well, Linus is not on his team, but if he was, he would say the same
thing. But probably at much higher rate than weekly.