Re: C23 thoughts and opinions

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

On 02/06/2024 15:29, Michael S wrote:

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. 

 
That's sort-of right.  To be precise for something like this, we'd
have to say what exactly we mean by "engine controller".  There are
many kinds of engine or motor, and many types of control that are
needed for them.  Generally, there is a hierarchy of simpler but more
time-critical parts up to more complex but more flexible parts of the
system.
 
As an example of a system of motor control that I've worked on
(electric motors rather than combustion engines), the most
timing-critical signal generation and safety (emergency stop,
overload protection, etc.) are all in hardware - typically dedicated
peripherals in the microcontroller.  Some safety parts might also be
implemented in non-maskable interrupt functions that the RTOS can
never disable.
 
The low-level control of the motors is typically run by timer
interrupt functions.  These may be disabled by the RTOS, but will
only be disabled for a very short (and predictable) time - interrupt
disabling is usually essential to the way locks and inter-process
communication works, including communication between these timer
functions and the rest of the code.  Higher level control runs as
RTOS tasks of various priorities, and communication with other boards
is usually a lower priority task.  Clearly these real-time tasks
cannot be more "real-time" than the RTOS itself.  Other boards might
have high level non-realtime system determining things like path
finding, or user interfaces.
 
And until you get to the highest level stuff, there is no reason why
C++ is not suitable.  But whether you use C++, C, Assembly, or Ada
for the low-level and more real-time critical code, you avoid dynamic
memory, exceptions, and other techniques that can have unpredictable
failure modes and unexpected delays.  (The high-level stuff can be
written in any language.)
 

 

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.  

 
I'd characterize it as whatever Scott says it is - he's the expert
there, not you or me.
 

You only care for buffers to not overflow. And if they
overflow, it's not too bad either. 

 
That is true for some things, but most certainly not for all usage.
 

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. 

 
There is a lot of networking that is not TCP/IP.
 
High-speed network interfaces are used for two purposes - to get high
throughput, or to get low latencies.  Throughput is not as sensitive
to timing and can tolerate some variation as long as the traffic is
independent, but latency is a different matter.
>

I think, nearly all work in high-end NIC is concentrated on throughput.
For low latency, the best you can do with high end NIC is to disable
all high-end features and to hope that in disabled state they do not
hurt you too badly.
It would be probably better to use specialized "dumb" NIC. I don't know
if such things exist, but considering that high-frequency trading is
still legal (IMHO, it shouldn't be) I would guess that they do.

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? 

 
Pretty sure, yes.
 

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. 

 
No, it is not simpler or more reliable.  Programmable logic is rarely
used for engine or motor control.  You use microcontrollers with
appropriate peripherals, such as sophisticated PWM units and encoder
interfaces, and advanced timers.
>

I was not talking about electric motors.

Even if MCU is $4.99 cheaper, the difference is a noise relatively
to price of engine. 

 
That part is true.
 

 

    

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.
 

 
Yes, but Linux Torvalds knows shit about C++.  He knows a lot about
C, and many other things.
 
He also - not unreasonably - believes that if C++ was used in the
Linux kernel, lots of others who know nothing about using C++ in OS's
and low-level work would make a complete mess of things.  You don't
want someone to randomly add std::vector<> or the like into kernel
code.  You don't want people who take delight in smart-arse coding,
such as some regulars in c.l.c++, anywhere near the kernel.
>

Or may be he understand that [for kernel] proclaimed advantages of C++
do not matter or matter too little. And disadvantage of higher
difficulty to see quickly what's going on, is real.

It is interesting to mention that experienced 46 y.o. Dave Cutler and
young student Linus Torvalds independently came to the same conclusion
w.r.t. to kernel language choice. That despite Cutler's employer being
very C++-oriented at that moment and despite most of the decisions
taken during the peak years of OO hype.
Unlike Torvalds, Cutler was not in a position to fully disable
development of 3-rd party kernel modules in C++, but he did his best to
discourage this practice.

But other OS's are not the Linux kernel - it has particularly unique
challenges.  If you have an appropriate team, C++ is vastly better
for writing RTOS kernels than C.
 

I find your statement unproven.
How many surviving and proliferating RTOS kernels are written in
each language?