On 10.08.24 22:06, Steve Litt wrote:

> Hendrik Boom said on Thu, 8 Aug 2024 10:51:40 -0400

>

> >On Thu, Aug 08, 2024 at 09:35:50AM -0500, o1bigtenor via Dng wrote:

> >> On Thu, Aug 8, 2024 at 8:52 AM Dan Purgert via Dng

> >>

> >> Why is C/C++ so absolutely wonderful?

> >

> >Primarily because C (not C++) has been around for a longer time

> >than most other tools.  Old enough that it was around when Linux got

> >written and it has become the interlingua for Linux software.

> >

> >Not because it's a great language.

>

> I think it's a pretty darn good language. It makes sense, its syntax is

> pretty guessable (except for pointers to functions), and it's a small

> language that's easily learned.

>

> >

> >It was a breath of fresh air in the 1970's, but by now language

> >technology has advanced a lot since then.

>

> I wouldn't be caught dead doing threads in C.

>

Having only done Embedded development (software & some hardware) in a 30

year career (now 16 years behind me), I only used assembler and C. In the

latter case, no heap, as malloc is indeterministic, so unviable in hard

realtime. There were times where a DIY block allocator was used, e.g.

for message packets - with fixed block size, it could always grab the

first available, and so was deterministic. (And a memory leak would

interfere with the design goal of 25 year uptime.)

Much of the embedded work was telecoms call control - up to hundreds of

threads, one per concurrent call, using one state machine code base. The

design language was ITUT SDL (Specification Z.100), allowing any mix of

interacting state machines, each with any number of threads. (Max fixed

at run-time.)

I grant that C is not ideal for implementing that ... so I sometimes did

it in assembler - sort of. Using DIY macros, it was not difficult to

create a limited macro-language providing states, transitions, signal

(event) handling, and instance variable handling to the degree needed.

The queues and multi-threaded timer service needed was fun to implement.

Purely event-driven software is a bit different. There can be no looping

or long-winded processing in a state transition as it is merely

cooperatively multi-tasking.

And in the early days, there were no compilers for the little 8-bit

microcontrollers used. (Though one system had 13 of them, hierarchically

handling network interface, call control, and system supervision. With

an average of 62.5 uS per trunk channel at the top, and a 0.6 MIPS

processor, assembler and dodging averages were it - in 1982.)

Porting an RTOS implementation from 68000 assembler to PowerPC was a fun

month's work, involving learning both those instruction sets, and

providing an interesting comparison. I'd rather do that than muck with

C++ any day.

Being able to build the GNU toolchain for 68000, PowerPC, V850, AVR,

etc. from project to project was productivity enhancing. And always

working on HP-UX, Solaris, Linux over the decades, with Vi then Vim,

gcc, and exuberant ctags, "*nix is the IDE" was manifest.

I remember an NEC engineer asking "Is gcc code vulnerable to the SLD &

SST instruction hardware bug on the V850?" It didn't take long to be

able to answer that Nick Clifton had obviated the issue in August 2005.

I seriously doubt that could have been established in ten minutes if

we'd used a commercial toolchain.

And I still value understanding that gobbeldygook like "dereferencing"

merely refers to "indirect addressing", something that pretty much every

processor has in its instruction set. Not all syntactic sugar is beneficial, I think.

Erik

--

I can only reply that I arrived at it by experimenting until I found

something that works, and then stopping.    - Rick Moen, on luv-main