?Is C++ Dead??
˙˙˙ https://deepengineering.substack.com/p/is-c-deadh most
?According to the January TIOBE Index, C++ is currently the fourt
popular programming language after C and Python. C++ is the main
programming language used in many critical systems, including hospitals,
cars, and airplanes. But dare I say it: C++ is prone to errors. And in
2024, even the U.S. government chipped in. They dropped the bomb: C and
C++ are not memory-safe programming languages. In 2026, might C++ be
seeing its last days??
˙˙˙ https://www.tiobe.com/tiobe-index/
˙
https://bidenwhitehouse.archives.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf
No, not even close to starting to die.˙ New projects are being started
in C++ daily.
Lynn
2024, even the U.S. government chipped in. They dropped the bomb: C and
C++ are not memory-safe programming languages.
In 2026, might C++ be seeing its last days??
The fact for me: I rarely encounter 'memory-safe' problems in C++.
... New programmers would not use C++. Experienced programmers would likely choose C++.
On 3/6/2026 5:19 AM, Lynn McGuire wrote:
2024, even the U.S. government chipped in. They dropped the bomb: C and
C++ are not memory-safe programming languages.
That's why operating systems manage and secure memory. Most operating systems are written in C and maybe with C++ attachment.
In 2026, might C++ be seeing its last days??
Not in business applications, I suppose. would Java die in 2026? Would
C# rise to power in 2026? :)
C#? Garbage collected crap? I know how to use it, but I don't reallyI suspect many stock trading and quoting systems were written in C for
like it.
On 3/5/2026 8:48 PM, Mr. Man-wai Chang wrote:
On 3/6/2026 5:19 AM, Lynn McGuire wrote:
2024, even the U.S. government chipped in. They dropped the bomb:
C and C++ are not memory-safe programming languages.
That's why operating systems manage and secure memory. Most
operating systems are written in C and maybe with C++ attachment.
In 2026, might C++ be seeing its last days??
Not in business applications, I suppose. would Java die in 2026?
Would C# rise to power in 2026? :)
C#? Garbage collected crap? I know how to use it, but I don't really
like it.
What about Q#? ;^)
Both Java and C# are garbage-collected languages.Coders, developers and programmers need to make a living and they will
Garbage-collected language is a right choice for business applications
in overwhelming majority of cases.
Is C# better than Java? Probably. But probably not by much.
I like Go better than either of them, but it does not appear to stand a chance in this battle.
On 3/8/2026 2:03 AM, Michael S wrote:
Coders, developers and programmers need to make a living and they will always choose the programming language that actually does the job. They
Both Java and C# are garbage-collected languages.
Garbage-collected language is a right choice for business applications
in overwhelming majority of cases.
Is C# better than Java? Probably. But probably not by much.
I like Go better than either of them, but it does not appear to stand a
chance in this battle.
are not paid to stay in the irovy towers of the acamdeic world! :)
Programmers rarely choose their programming language for
their day job - they use what the job says they should use. ...
Am 08.03.2026 um 11:49 schrieb David Brown:
Programmers rarely choose their programming language for
their day job - they use what the job says they should use. ...
No, they chose the job with the lanugage they like.
On 08/03/2026 09:26, Mr. Man-wai Chang wrote:
On 3/8/2026 2:03 AM, Michael S wrote:
Coders, developers and programmers need to make a living and they will
Both Java and C# are garbage-collected languages.
Garbage-collected language is a right choice for business applications
in overwhelming majority of cases.
Is C# better than Java? Probably. But probably not by much.
I like Go better than either of them, but it does not appear to stand a
chance in this battle.
always choose the programming language that actually does the job.
They are not paid to stay in the irovy towers of the acamdeic world! :)
Programmers rarely choose their programming language for their day job - they use what the job says they should use.˙ They can choose what they
want for their own coding, and that can influence what job they get, but
for most programmers, the language they use is what the boss says they
must use - even if they know they could do a better job in a different language.
On 08/03/2026 16:46, Bonita Montero wrote:
Am 08.03.2026 um 11:49 schrieb David Brown:
Programmers rarely choose their programming language for
their day job - they use what the job says they should use. ...
No, they chose the job with the lanugage they like.
Some can do that.˙ Some can also choose the language that their employer uses.˙ But most programmers get a job that they can get, and do what the
job requires - just like most non-programmers.
Coders, developers and programmers need to make a living and they will always choose the programming language that actually does the job. They
are not paid to stay in the irovy towers of the acamdeic world! :)
On 3/6/2026 5:19 AM, Lynn McGuire wrote:
2024, even the U.S. government chipped in. They dropped the bomb: C and
C++ are not memory-safe programming languages.
That's why operating systems manage and secure memory. Most operating systems are written in C and maybe with C++ attachment.
In 2026, might C++ be seeing its last days??
Not in business applications,
I suppose. would Java die in 2026?
Would C# rise to power in 2026? :)
Am 06.03.26 um 05:48 schrieb Mr. Man-wai Chang:
On 3/6/2026 5:19 AM, Lynn McGuire wrote:
2024, even the U.S. government chipped in. They dropped the bomb: C and
C++ are not memory-safe programming languages.
That's why operating systems manage and secure memory. Most operating
systems are written in C and maybe with C++ attachment.
Linux recently added Rust to the kernel. I think at long term they will prefer Rust.
In 2026, might C++ be seeing its last days??
Not in business applications,
Well, it depends on what you call "last". ;-)
Due to the existing code base it will survive some decades. But every language has its height.
I suppose. would Java die in 2026?
The Java license is potential harmful. Oracle may kill OpenJDK by making
the certification too complex and too expensive.
Would C# rise to power in 2026? :)
The C# license is not that restrictive, and C# has become somewhat
superior to Java regarding features and performance. But both are still
far behind C++.
On the other side the larger existing code base will keep Java alive, at least for business.
C++ has become too complex for many programmers. This is an economic disadvantage from the business point of view. So people move to a newer, simpler language with less features. Until it becomes too complex, of course. New hardware (to compensate for performance) is always cheaper
that programmers, who write efficient code.
Marcel
If a boss of mine asks me to code something in C#, I will. But, just
won't like it all that much. Remember that managed C++ thing from MS?
C++ has become too complex for many programmers. This is an economic disadvantage from the business point of view. So people move to a newer, simpler language with less features. Until it becomes too complex, of
course. New hardware (to compensate for performance) is always cheaper
that programmers, who write efficient code.
If C++ is too complex for a programmer then the programmer is not a good programmer.
Am 08.03.2026 um 22:38 schrieb Chris M. Thomasson:
If a boss of mine asks me to code something in C#, I will. But, just
won't like it all that much. Remember that managed C++ thing from MS?
C# is a great language for business applications. It's more mature
than Java. Java evolves very slowly and I don't understand why.
Am 08.03.2026 um 22:38 schrieb Chris M. Thomasson:
If a boss of mine asks me to code something in C#, I will. But, just
won't like it all that much. Remember that managed C++ thing from MS?
C# is a great language for business applications. It's more mature
than Java. Java evolves very slowly and I don't understand why.
Lynn McGuire <LynnMcGuire5@GMail.com> wrote: |-------------------------------------------------------------------------| |"?Is C++ Dead?? |
| https://deepengineering.substack.com/p/is-c-dead |
| | |?[. . .] | |[ . .] C++ is the main | |programming language used in many critical systems, including hospitals, | |cars, and airplanes. [. . .] | |[. . .] | |[. ..]?" | |-------------------------------------------------------------------------|
Oh dear!
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
In comp.lang.ada Tristan Wibberley <tristan.wibberley+netnews2@alumni.Manchester.ac.UK> wrote: |----------------------------------------------------------------------|
|"[. . .] I worked in automotive software | |engineering for a time and it gave me fewer hairs to raise" | |----------------------------------------------------------------------|
Dear Doctor Wibberley,
What does this mean?
|----------------------------------------------------------------------|
|" and I didn't | |stay long enough to get combed into an automotive software engineer - | |just long enough to recognise the incredible breadth and depth of | |problems, expertise, focus, risk-management, steadfastness, pushback, | |pace, etc..." | |----------------------------------------------------------------------|
I do not work on cars, but perhaps Doctor Wibberley gives cars workers
too much credit. A car-software programmer who is worryingly ignorant
of the compiler that he uses (which I used to use) disturbs me. I know
a dangerous risk taker who works on automotive electronics, who
falsely professes to be an electronic engineer.
I encountered C# cars workers who dangerously misbehave.
An electronic-engineering lecturer said that BMW or Mercedes
outsources cars work to him, but that he is too poor to buy a car from
this manufacturer ...
... such that it is not as big a problem to him if these
cars are not safe.
|----------------------------------------------------------------------| |"Safe software engineering is almost nothing to do with C++;" | |----------------------------------------------------------------------|
Safe software has nothing to do with C++. Software engineering has
nothing to do with C++.
|----------------------------------------------------------------------|
|" I suspect |
|C++ is used for reasons of historical evolution of assurance combined | |with matters of the employment market rather than any other reasons." | |----------------------------------------------------------------------|
C++ is used because managers are anti-engineering chancers.
C++ is
used instead of plain C because Bjarne Stroustrup decides to win over
C hackers by choosing against good
decisions. Cf. \cite{The_Design_and_Evolution_of_C++}.
C is used because 1 of the 1st non-country non-university users of
computers made C.
Anti-engineering chancers managers choose C++ because many persons
enroll in a C++ course and few persons enroll in Ada courses.
These
managers do not appreciate that engineers instead of bugs makers use
Ada instead of C++, such that the big supply of C++ hackers is not a
benefit.
Does Lynn McGuire or anyone else disagree that Eric Naggum published:
"C++ is a language strongly optimized for liars and people who go by guesswork and ignorance."
Does Lynn McGuire or anyone else disagree that Bjarne Stroustrup
says "Within C++, there is a much smaller and cleaner language
struggling to get out."
I suspect that once upon a time they used linker+c but boilerplate
reduction and the gradual obsolescence of linker scripts to control
memory layout lead to C++ and custom layout tools.
Lynn McGuire <LynnMcGuire5@GMail.com> wrote: |-------------------------------------------------------------------------| |"On 3/9/2026 2:27 AM, Marcel Mueller wrote: | |[. . .] |
C++ has become too complex for many programmers. [. . .] | [. . .] | [. . .] | [. . .] | [. . .] || | |If C++ is too complex for a programmer then the programmer is not a good | |programmer. |
|
| Marcel |
| | |[. . .] | |[. . .] | |[. . .] |
| | |Lynn" | |-------------------------------------------------------------------------|
I joined the Association of C & C++ Users more than twenty-six years
ago. I do not recall ever seeing Lynn McGuire listed in a membership directory thereof. I also do not recall any ACCU publication by her.
Does Lynn McGuire or anyone else disagree that Bjarne Stroustrup says
"Within C++, there is a much smaller and cleaner language struggling
to get out." Does Lynn McGuire or anyone else disagree that Francis Glassborow publishes similarly?
Does Lynn McGuire or anyone else disagree that Eric Naggum published:
that C++'s "unmanageable complexity has spawned more fear-preventing
tools than any other language, but the solution should have been to
create and use a language that does not overload the whole goddamn
human."?
Does Lynn McGuire or anyone else disagree that Eric Naggum published:
"I may be biased, but I tend to find a much lower tendency among
female programmers to be dishonest about their skills, and thus do not
say they know C++ when they are smart enough to realize that that
would be a lie for all but perhaps 5 people on this planet."?
Does Lynn McGuire or anyone else disagree that Eric Naggum published:
"C++ is a language strongly optimized for liars and people who go by guesswork and ignorance."
Does Lynn McGuire believe that Bjarne Stroustrup; Francis Glassborow;
and Eric Naggum are "not [. . .] good programmer"s?
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
On Sun, 15 Mar 2026 19:13:11 -0000 (UTC), Niocl s P˘l Caile n de
Ghloucester wrote:
Does Lynn McGuire or anyone else disagree that Bjarne Stroustrup
says "Within C++, there is a much smaller and cleaner language
struggling to get out."
?Just the one, dear??
-- June Whitfield in ?Absolutely Fabulous?
Lynn McGuire <LynnMcGuire5@GMail.com> wrote: >|-------------------------------------------------------------------------| >|"On 3/9/2026 2:27 AM, Marcel Mueller wrote: | >|[. . .] | >|> C++ has become too complex for many programmers. [. . .] | >|> [. . .] | >|> [. . .] | >|> [. . .] | >|> [. . .] | >|> | >|> | >|> Marcel |
| | >|If C++ is too complex for a programmer then the programmer is not a good | >|programmer. |
| | >|[. . .] | >|[. . .] | >|[. . .] |
| | >|Lynn" | >|-------------------------------------------------------------------------|
I joined the Association of C & C++ Users more than twenty-six years
ago. I do not recall ever seeing Lynn McGuire listed in a membership >directory thereof. I also do not recall any ACCU publication by her.
Does Lynn McGuire or anyone else disagree that Bjarne Stroustrup says
"Within C++, there is a much smaller and cleaner language struggling
to get out." Does Lynn McGuire or anyone else disagree that Francis >Glassborow publishes similarly?
Does Lynn McGuire or anyone else disagree that Eric Naggum published:
that C++'s "unmanageable complexity has spawned more fear-preventing
tools than any other language, but the solution should have been to
create and use a language that does not overload the whole goddamn
human."?
Does Lynn McGuire or anyone else disagree that Eric Naggum published:
"I may be biased, but I tend to find a much lower tendency among
female programmers to be dishonest about their skills, and thus do not
say they know C++ when they are smart enough to realize that that
would be a lie for all but perhaps 5 people on this planet."?
Does Lynn McGuire or anyone else disagree that Eric Naggum published:
"C++ is a language strongly optimized for liars and people who go by >guesswork and ignorance."
Does Lynn McGuire believe that Bjarne Stroustrup; Francis Glassborow;
and Eric Naggum are "not [. . .] good programmer"s?
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
On Sun, 15 Mar 2026 15:37:59 +0000, Tristan Wibberley wrote:
I suspect that once upon a time they used linker+c but boilerplate
reduction and the gradual obsolescence of linker scripts to control
memory layout lead to C++ and custom layout tools.
Does Lynn McGuire believe that Bjarne Stroustrup; Francis Glassborow;
and Eric Naggum are "not [. . .] good programmer"s?
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
If you want to know what Erik Naggum thought, there's an archive of
his comp.lang.lisp postings at https://xach.com/naggum/articles/.
Erik definitely had some strong opinions re: C and C++, and he had
good reasons for most of them. He is sorely missed.
On Sun, 15 Mar 2026 15:37:59 +0000, Tristan Wibberley wrote:
I suspect that once upon a time they used linker+c but boilerplate
reduction and the gradual obsolescence of linker scripts to control
memory layout lead to C++ and custom layout tools.
eh, well, they're were still there internal to the build processes when
I was working in automotive but they were often machine-translations
from other sources, even via attributes and toolchain flags (because >command-orientation is a common human trait).
On 3/15/2026 2:13 PM, Niocl s P˘l Caile n de Ghloucester wrote:Try to rewrite (or examine) the idea in CSCall OO concept (reset rules).
Lynn McGuire <LynnMcGuire5@GMail.com> wrote:
-------------------------------------------------------------------------|
"On 3/9/2026 2:27 AM, Marcel Mueller wrote:˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ |
[. . .]˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ |
C++ has become too complex for many programmers. [. . .]˙˙˙˙˙˙˙˙˙˙˙˙˙˙ |˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ | If C++ is too complex for a programmer then the programmer is not a good |
[. . .]˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ |
[. . .]˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ |
[. . .]˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ |
[. . .]˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ |
˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ |
˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ |
Marcel˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ |
programmer.˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ |
˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ | [. . .]˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ |
[. . .]˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ |
[. . .]˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ |
˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ | Lynn"˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙˙ |
-------------------------------------------------------------------------|
I joined the Association of C & C++ Users more than twenty-six years
ago. I do not recall ever seeing Lynn McGuire listed in a membership directory thereof. I also do not recall any ACCU publication by her.
Does Lynn McGuire or anyone else disagree that Bjarne Stroustrup says "Within C++, there is a much smaller and cleaner language struggling
to get out." Does Lynn McGuire or anyone else disagree that Francis Glassborow publishes similarly?
Does Lynn McGuire or anyone else disagree that Eric Naggum published:
that C++'s "unmanageable complexity has spawned more fear-preventing
tools than any other language, but the solution should have been to
create and use a language that does not overload the whole goddamn
human."?
Does Lynn McGuire or anyone else disagree that Eric Naggum published:
"I may be biased, but I tend to find a much lower tendency among
female programmers to be dishonest about their skills, and thus do not
say they know C++ when they are smart enough to realize that that
would be a lie for all but perhaps 5 people on this planet."?
Does Lynn McGuire or anyone else disagree that Eric Naggum published:
"C++ is a language strongly optimized for liars and people who go by guesswork and ignorance."
Does Lynn McGuire believe that Bjarne Stroustrup; Francis Glassborow;
and Eric Naggum are "not [. . .] good programmer"s?
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
Lynn McGuire is a he.˙ 6'1" and bald with a full beard.˙ Running an engineering software company since 1995.
Member of ASME and AIChE.˙ Graduate of Texas A&M University in 1982 with Mechanical Engineering degree.˙ Licensed Professional Engineer in the
The Great State of Texas since 1989.
Commercial Fortran programmer since 1975.˙ Converted to
Pascal in 1983.˙ Converted to C in 1987.˙ Converted to C++ in 2001.
Just another engineer writing commercial software.
Lynn
Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> writes:
On 15/03/2026 22:23, Lawrence D?Oliveiro wrote:
On Sun, 15 Mar 2026 15:37:59 +0000, Tristan Wibberley wrote:
I suspect that once upon a time they used linker+c but boilerplate
reduction and the gradual obsolescence of linker scripts to control
memory layout lead to C++ and custom layout tools.
eh, well, they're were still there internal to the build processes when
I was working in automotive but they were often machine-translations
from other sources, even via attributes and toolchain flags (because
command-orientation is a common human trait).
There is still a lot of standalone (sans-OS) code written
in both C and C++, and linker scripts are far from obsolete.
In comp.lang.ada George Neuner <gneuner2@Comcast.net> wrote: >|---------------------------------------------------------------------|
|"If you want to know what Erik Naggum thought, there's an archive of |
|his comp.lang.lisp postings at https://xach.com/naggum/articles/. "| >|---------------------------------------------------------------------|
This is another example where George Neuner taught me via another of
his insights. Thanks! I suspect that HTTPS://Xach.com/naggum/articles
does not archive all of Naggum's comp.lang.lisp postings which were
marked with an anti-archiving header.
(S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
If C++ is too complex for a programmer then the programmer is not
a good programmer.
The only exception to that is multiple thread software.˙That stuff
is dadgum complicated.˙But the multiple thread software is not used
very often in my circles.
Am 09.03.2026 um 23:36 schrieb Lynn McGuire:
If C++ is too complex for a programmer then the programmer is not
a good programmer.
I'm a good C++ programmer but I admit that C++ is much less readable
as for example Rust. And both languages server the same purpose. But
I still like C++.
The only exception to that is multiple thread software.˙That stuff
is dadgum complicated.˙But the multiple thread software is not used
very often in my circles.
Most MT-algoritms are easy (embarassingly parallel).
Spinning off threads is easy. Deciding which variables to mutex is not.
˙Especially in software hundreds of thousands of lines of of C++ long.
Am 18.03.2026 um 20:21 schrieb Lynn McGuire:
Spinning off threads is easy. Deciding which variables to mutex is
not. ˙Especially in software hundreds of thousands of lines of of C++
long.
Code may be that long, but locking scopes are never so long.
On 3/18/2026 1:09 PM, Bonita Montero wrote:
Am 09.03.2026 um 23:36 schrieb Lynn McGuire:
If C++ is too complex for a programmer then the programmer is not
a good programmer.
I'm a good C++ programmer but I admit that C++ is much less readable
as for example Rust. And both languages server the same purpose. But
I still like C++.
The only exception to that is multiple thread software.˙That stuff
is dadgum complicated.˙But the multiple thread software is not used
very often in my circles.
Most MT-algoritms are easy (embarassingly parallel).
Spinning off threads is easy. Deciding which variables to mutex is not.
Especially in software hundreds of thousands of lines of of C++ long.
My Windows user interface is well over 500,000 lines of C++ code.
Lynn McGuire <lynnmcguire5@gmail.com> writes:
On 3/18/2026 1:09 PM, Bonita Montero wrote:
Am 09.03.2026 um 23:36 schrieb Lynn McGuire:
If C++ is too complex for a programmer then the programmer is not
a good programmer.
I'm a good C++ programmer but I admit that C++ is much less readable
as for example Rust. And both languages server the same purpose. But
I still like C++.
The only exception to that is multiple thread software.˙That stuff
is dadgum complicated.˙But the multiple thread software is not used
very often in my circles.
Most MT-algoritms are easy (embarassingly parallel).
Spinning off threads is easy. Deciding which variables to mutex is not.
As someone with four decades of multitheaded programming experience
at both the lowest levels (OS) and highest levels (applications),
I strongly disagree.
It's very easy to determine whether a particular datum is
subject to concurrent access based on understanding the
underlying algorithms used.
Especially in software hundreds of thousands of lines of of C++ long.
My Windows user interface is well over 500,000 lines of C++ code.
Ah, windows. Sigh.
My current project at work is over 3 million lines of C++ code, and
leverages 64 physical cores using over 120 threads (pthreads)
with pretty much 100% utilization across all the cores.
The nice thing about C++ is that if you do it right, all the
locking is almost always encapsulated within a class (e.g.
a class member and associated member functions), which naturally
restricts the scope of the lock to within the class.
Am 18.03.2026 um 20:21 schrieb Lynn McGuire:
Spinning off threads is easy. Deciding which variables to mutex is
not. ˙Especially in software hundreds of thousands of lines of of C++
long.
Code may be that long, but locking scopes are never so long.
On 3/18/2026 4:24 PM, Scott Lurndal wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
On 3/18/2026 1:09 PM, Bonita Montero wrote:
Am 09.03.2026 um 23:36 schrieb Lynn McGuire:
If C++ is too complex for a programmer then the programmer is not
a good programmer.
I'm a good C++ programmer but I admit that C++ is much less readable
as for example Rust. And both languages server the same purpose. But
I still like C++.
The only exception to that is multiple thread software.˙That stuff
is dadgum complicated.˙But the multiple thread software is not used
very often in my circles.
Most MT-algoritms are easy (embarassingly parallel).
Spinning off threads is easy.˙ Deciding which variables to mutex is not.
As someone with four decades of multitheaded programming experience
at both the lowest levels (OS) and highest levels (applications),
I strongly disagree.
It's very easy to determine whether a particular datum is
subject to concurrent access based on understanding the
underlying algorithms used.
˙ Especially in software hundreds of thousands of lines of of C++ long.
My Windows user interface is well over 500,000 lines of C++ code.
Ah, windows.˙ Sigh.
My current project at work is over 3 million lines of C++ code, and
leverages 64 physical cores using over 120 threads (pthreads)
with pretty much 100% utilization across all the cores.
Nice !˙ Good job.
The nice thing about C++ is that if you do it right, all the
locking is almost always encapsulated within a class (e.g.
a class member and associated member functions), which naturally
restricts the scope of the lock to within the class.
It is always, "if you do it right".
On 3/18/2026 2:41 PM, Lynn McGuire wrote:
On 3/18/2026 4:24 PM, Scott Lurndal wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
On 3/18/2026 1:09 PM, Bonita Montero wrote:
Am 09.03.2026 um 23:36 schrieb Lynn McGuire:
If C++ is too complex for a programmer then the programmer is not
a good programmer.
I'm a good C++ programmer but I admit that C++ is much less readable >>>>> as for example Rust. And both languages server the same purpose. But >>>>> I still like C++.
The only exception to that is multiple thread software.˙That stuff >>>>>> is dadgum complicated.˙But the multiple thread software is not used >>>>>> very often in my circles.
Most MT-algoritms are easy (embarassingly parallel).
Spinning off threads is easy.˙ Deciding which variables to mutex is
not.
As someone with four decades of multitheaded programming experience
at both the lowest levels (OS) and highest levels (applications),
I strongly disagree.
It's very easy to determine whether a particular datum is
subject to concurrent access based on understanding the
underlying algorithms used.
˙ Especially in software hundreds of thousands of lines of of C++ long. >>>>
My Windows user interface is well over 500,000 lines of C++ code.
Ah, windows.˙ Sigh.
My current project at work is over 3 million lines of C++ code, and
leverages 64 physical cores using over 120 threads (pthreads)
with pretty much 100% utilization across all the cores.
Nice !˙ Good job.
The nice thing about C++ is that if you do it right, all the
locking is almost always encapsulated within a class (e.g.
a class member and associated member functions), which naturally
restricts the scope of the lock to within the class.
It is always, "if you do it right".
If you decide to use threads. Make sure to learn about mutex and condvar first! Then learn about embarrassingly parallel, where no mutex and
condvar are "necessarily" needed. Then ponder on lock-free.
Make sure to never have to use lock-free unless you absolutely have to!
Fwiw, I used to converse with David Butenhof back on comp.programming.threads. Nice guy, and wrote a nice book to read before
you even go into C++ threads, perhaps. Well... ? I remember he was
pondering on writing another book, cooking with posix threads.
https://www.amazon.com/Programming-POSIX-Threads-David-Butenhof/ dp/0201633922
:^) Real all of it, then ponder on how C++ is there ready willing and able.
I have a copy of "C++ Concurrency in Action: Practical Multithreading"
First Edition by Anthony Williams.˙ I have yet to read it though.
https://www.amazon.com/C-Concurrency-Action-Practical-Multithreading/ dp/1933988770/
Lynn McGuire <lynnmcguire5@gmail.com> writes:
On 3/18/2026 1:09 PM, Bonita Montero wrote:
Am 09.03.2026 um 23:36 schrieb Lynn McGuire:
If C++ is too complex for a programmer then the programmer is not
a good programmer.
I'm a good C++ programmer but I admit that C++ is much less readable
as for example Rust. And both languages server the same purpose. But
I still like C++.
The only exception to that is multiple thread software.˙That stuff
is dadgum complicated.˙But the multiple thread software is not used
very often in my circles.
Most MT-algoritms are easy (embarassingly parallel).
Spinning off threads is easy. Deciding which variables to mutex is not.
As someone with four decades of multitheaded programming experience
at both the lowest levels (OS) and highest levels (applications),
I strongly disagree.
It's very easy to determine whether a particular datum is
subject to concurrent access based on understanding the
underlying algorithms used.
It is always, "if you do it right".
If you decide to use threads. Make sure to learn about mutex and condvar first! Then learn about embarrassingly parallel, where no mutex and
condvar are "necessarily" needed. Then ponder on lock-free.
Make sure to never have to use lock-free unless you absolutely have to!
= (*m_begin.itChunks)->end() )return false;
Am 19.03.2026 um 03:58 schrieb Chris M. Thomasson:
If you decide to use threads. Make sure to learn about mutex and
condvar first! Then learn about embarrassingly parallel, where no
mutex and condvar are "necessarily" needed. Then ponder on lock-free.
Embarassingly parallel doesn't mean that no mutexes or
condvars are necessary, just that parallelizing was easy.
Make sure to never have to use lock-free unless you absolutely have to!
There are only two definitive lock-free algorithms: lock-free stacks
and lock free queues.
On 18/03/2026 22:24, Scott Lurndal wrote:
Lynn McGuire <lynnmcguire5@gmail.com> writes:
On 3/18/2026 1:09 PM, Bonita Montero wrote:
Am 09.03.2026 um 23:36 schrieb Lynn McGuire:
If C++ is too complex for a programmer then the programmer is not
a good programmer.
I'm a good C++ programmer but I admit that C++ is much less readable
as for example Rust. And both languages server the same purpose. But
I still like C++.
The only exception to that is multiple thread software.˙That stuff
is dadgum complicated.˙But the multiple thread software is not used
very often in my circles.
Most MT-algoritms are easy (embarassingly parallel).
Spinning off threads is easy.˙ Deciding which variables to mutex is not.
As someone with four decades of multitheaded programming experience
at both the lowest levels (OS) and highest levels (applications),
I strongly disagree.
It's very easy to determine whether a particular datum is
subject to concurrent access based on understanding the
underlying algorithms used.
It can be easy to determine what data needs protected by mutexes, but
not nearly as easy to determine when the mutexes should be locked and unlocked in sequences that are maximally efficient.˙ If a thread takes a lock, and is doing two different things with the data, should it release
the lock and re-take it in the middle?
thread, as the release and re-lock is not free.˙ But /not/ doing so
could hinder progress for another thread.˙ Then you have questions about
how fine-grained your mutexes should be, and how to coordinate cases
where you need multiple mutexes.˙ And of course you have the bigger architectural questions - should the data be shared and locked by a
mutex, or use a message queue, or atomics, or duplicate copies of the
data, or some other sharing and synchronisation solution?
So yes, determining what data to protect is usually easy.˙ Determining
how best to do that is the fun part.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 15 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 180:29:20 |
| Calls: | 213 |
| Files: | 21,502 |
| Messages: | 84,274 |