Re: C23 thoughts and opinions

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.

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.

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.
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.