Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #385446

Re: C23 thoughts and opinions

Show all headers | View raw

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?

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-24 07:36 +0200
  Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-24 09:32 +0200
    Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-24 18:34 +0200
      Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 09:13 +0200
        Re: C23 thoughts and opinions Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-26 13:23 +0200
          Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-27 00:55 +0000
          Re: C23 thoughts and opinions Lynn McGuire <lynnmcguire5@gmail.com> - 2024-05-31 18:34 -0500
            Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-01 01:27 +0000
              Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-02 11:02 +0300
                Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-02 14:03 +0200
                Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-02 16:29 +0300
                Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-02 19:23 +0000
                Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-02 21:44 +0200
                Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-03 12:00 +0300
                Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-03 18:34 +0200
                Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-03 16:50 +0000
                Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-03 21:05 +0200
                Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-03 19:38 +0000
                Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-03 22:58 +0300
                Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-03 21:22 +0000
                Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-04 05:17 +0000
                Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-06-04 11:23 +0300
                Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-04 10:25 +0200
                Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-04 13:30 +0000
                Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-04 12:48 -0500
                Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-04 19:17 +0000
                Re: C23 thoughts and opinions BGB-Alt <bohannonindustriesllc@gmail.com> - 2024-06-04 17:32 -0500
                Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-05 07:22 +0000
                Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-05 07:14 +0000
                Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-05 04:01 -0500
                Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 00:57 +0000
                Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-07 02:52 -0500
                Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-14 03:20 +0000
                Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-05 07:15 +0000
                Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-05 13:32 +0000
                Re: C23 thoughts and opinions cross@spitfire.i.gajendra.net (Dan Cross) - 2024-06-05 13:59 +0000
                Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-07 00:59 +0000
                Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-04 05:12 +0000
                Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-04 06:55 +0000
                Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-02 19:15 +0000
                Re: C23 thoughts and opinions "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-02 12:46 -0700
                Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-03 03:21 +0000
                Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-03 14:16 +0000
                Re: C23 thoughts and opinions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-03 13:23 -0700
                Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-04 13:46 -0500
                Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-04 19:21 +0000
                Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-04 20:44 -0500
                Re: C23 thoughts and opinions Paul <nospam@needed.invalid> - 2024-06-04 23:59 -0400
                Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-05 00:44 -0500
                Re: C23 thoughts and opinions scott@slp53.sl.home (Scott Lurndal) - 2024-06-05 13:29 +0000
                Re: C23 thoughts and opinions BGB <cr88192@gmail.com> - 2024-06-05 13:49 -0500
                Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-03 21:14 +0200
            Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-06-01 15:28 +0200
              Re: C23 thoughts and opinions Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-01 16:33 +0100
                Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-02 03:28 +0000
    Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-25 21:24 +0000
      Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 08:32 +0200
        Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-26 02:48 -0700
          Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 13:44 +0200
            Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 15:39 +0300
              Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 15:46 +0200
                Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 17:20 +0300
                Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-26 16:29 +0200
                Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 18:05 +0300
                Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-26 18:26 +0200
                Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 19:50 +0300
                Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-28 05:41 +0000
                Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-28 10:46 +0300
                Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 17:10 +0200
                Re: C23 thoughts and opinions Michael S <already5chosen@yahoo.com> - 2024-05-26 18:23 +0300
                Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 19:23 +0200
                Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-26 18:36 +0200
                Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 19:11 +0200
                Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-26 16:30 -0700
                Re: C23 thoughts and opinions David Brown <david.brown@hesbynett.no> - 2024-05-27 10:45 +0200
                Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-28 05:45 +0000
                Re: C23 thoughts and opinions Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-05-26 13:53 -0700
            Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-26 21:16 +0000
              Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-27 07:14 +0200
          Re: C23 thoughts and opinions Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-05-27 00:53 +0000
        Re: C23 thoughts and opinions Kaz Kylheku <643-408-1753@kylheku.com> - 2024-05-26 21:03 +0000
      Re: C23 thoughts and opinions jak <nospam@please.ty> - 2024-05-26 08:44 +0200

csiph-web