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

Groups > comp.lang.c++ > #122678 > unrolled thread

"Brian Kernigan speaks. 83 and still teaching."

Back to article view | Back to comp.lang.c++

Contents

  "Brian Kernigan speaks. 83 and still teaching." Lynn McGuire <lynnmcguire5@gmail.com> - 2025-09-01 23:39 -0500
    Re: "Brian Kernigan speaks. 83 and still teaching." Lynn McGuire <lynnmcguire5@gmail.com> - 2025-09-02 20:34 -0500
    Re: "Brian Kernigan speaks. 83 and still teaching." Pierre <null@void.net> - 2025-09-03 22:20 +0000
      Re: "Brian Kernigan speaks. 83 and still teaching." Bonita Montero <Bonita.Montero@gmail.com> - 2025-09-04 02:10 +0200
        Re: "Brian Kernigan speaks. 83 and still teaching." scott@slp53.sl.home (Scott Lurndal) - 2025-09-04 00:12 +0000
          Re: "Brian Kernigan speaks. 83 and still teaching." Kaz Kylheku <643-408-1753@kylheku.com> - 2025-09-04 02:30 +0000
            Re: "Brian Kernigan speaks. 83 and still teaching." 🇵🇱Jacek Marcin Jaworski🇵🇱 <jaworski1978@adres.pl> - 2025-09-04 18:33 +0200
              Re: "Brian Kernigan speaks. 83 and still teaching." Michael S <already5chosen@yahoo.com> - 2025-09-05 00:36 +0300
          Re: "Brian Kernigan speaks. 83 and still teaching." Beej Jorgensen <beej@beej.us> - 2025-09-07 17:50 +0000
            Re: "Brian Kernigan speaks. 83 and still teaching." Paavo Helde <eesnimi@osa.pri.ee> - 2025-09-08 09:13 +0300
              Re: "Brian Kernigan speaks. 83 and still teaching." "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-09-08 00:20 -0700
              Re: "Brian Kernigan speaks. 83 and still teaching." Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-08 08:43 +0000
                Re: "Brian Kernigan speaks. 83 and still teaching." candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-09-09 21:50 +0000
                  Re: "Brian Kernigan speaks. 83 and still teaching." Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-09 22:38 +0000
                    Re: "Brian Kernigan speaks. 83 and still teaching." candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-09-10 18:20 +0000
        Re: "Brian Kernigan speaks. 83 and still teaching." boltar@caprica.universe - 2025-09-04 08:36 +0000
          Re: "Brian Kernigan speaks. 83 and still teaching." Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-09-04 12:40 +0200
            Re: "Brian Kernigan speaks. 83 and still teaching." boltar@caprica.universe - 2025-09-04 15:57 +0000
              Re: "Brian Kernigan speaks. 83 and still teaching." Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-09-05 05:42 +0200
                Re: "Brian Kernigan speaks. 83 and still teaching." scott@slp53.sl.home (Scott Lurndal) - 2025-09-05 14:08 +0000
                  Re: "Brian Kernigan speaks. 83 and still teaching." David Brown <david.brown@hesbynett.no> - 2025-09-05 16:51 +0200
                    Re: "Brian Kernigan speaks. 83 and still teaching." boltar@caprica.universe - 2025-09-05 15:17 +0000
                    Re: "Brian Kernigan speaks. 83 and still teaching." wij <wyniijj5@gmail.com> - 2025-09-06 00:41 +0800
                    Re: "Brian Kernigan speaks. 83 and still teaching." wij <wyniijj5@gmail.com> - 2025-09-06 00:41 +0800
                    Re: "Brian Kernigan speaks. 83 and still teaching." Michael S <already5chosen@yahoo.com> - 2025-09-07 11:16 +0300
                      Re: "Brian Kernigan speaks. 83 and still teaching." David Brown <david.brown@hesbynett.no> - 2025-09-07 12:08 +0200
                        Re: "Brian Kernigan speaks. 83 and still teaching." wij <wyniijj5@gmail.com> - 2025-09-07 22:16 +0800
                        Re: "Brian Kernigan speaks. 83 and still teaching." boltar@caprica.universe - 2025-09-07 14:42 +0000
                          Re: "Brian Kernigan speaks. 83 and still teaching." David Brown <david.brown@hesbynett.no> - 2025-09-07 20:05 +0200
                      Re: "Brian Kernigan speaks. 83 and still teaching." scott@slp53.sl.home (Scott Lurndal) - 2025-09-07 15:30 +0000
                        Re: "Brian Kernigan speaks. 83 and still teaching." boltar@caprica.universe - 2025-09-07 16:00 +0000
                          Re: "Brian Kernigan speaks. 83 and still teaching." candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-09-09 21:50 +0000
                  Re: "Brian Kernigan speaks. 83 and still teaching." Lynn McGuire <lynnmcguire5@gmail.com> - 2025-09-05 13:58 -0500
                  Re: "Brian Kernigan speaks. 83 and still teaching." Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-09-06 01:14 +0200
                Re: "Brian Kernigan speaks. 83 and still teaching." James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-09-05 17:34 -0400
                  Re: "Brian Kernigan speaks. 83 and still teaching." Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-09-05 21:55 +0000
                    Re: "Brian Kernigan speaks. 83 and still teaching." Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-09-06 01:39 +0200
                    Re: "Brian Kernigan speaks. 83 and still teaching." scott@slp53.sl.home (Scott Lurndal) - 2025-09-06 17:46 +0000
                      Re: "Brian Kernigan speaks. 83 and still teaching." Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-09-06 18:38 +0000
                        Re: "Brian Kernigan speaks. 83 and still teaching." Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-08 08:41 +0000
                  Re: “Brian Kernigan speaks. 83 and still teaching.” Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-08 08:40 +0000
                    Re: “Brian Kernigan speaks. 83 and still teaching.” Louis Krupp <lkrupp@invalid.pssw.com.invalid> - 2025-09-10 01:21 -0600
          Re: "Brian Kernigan speaks. 83 and still teaching." Bonita Montero <Bonita.Montero@gmail.com> - 2025-09-04 23:40 +0200
        Re: "Brian Kernigan speaks. 83 and still teaching." Mario Rosell <usenet@mariorosell.es> - 2026-04-17 20:25 +0000
          Re: "Brian Kernigan speaks. 83 and still teaching." Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-19 00:10 +0000
          Re: "Brian Kernigan speaks. 83 and still teaching." "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2026-04-22 03:51 +0800
      Re: "Brian Kernigan speaks. 83 and still teaching." Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-08 08:36 +0000
        Re: "Brian Kernigan speaks. 83 and still teaching." Lynn McGuire <lynnmcguire5@gmail.com> - 2025-09-08 17:01 -0500
          Re: "Brian Kernigan speaks. 83 and still teaching." Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-08 22:43 +0000
            Re: "Brian Kernigan speaks. 83 and still teaching." Lynn McGuire <lynnmcguire5@gmail.com> - 2025-09-08 17:57 -0500
          Re: "Brian Kernigan speaks. 83 and still teaching." scott@slp53.sl.home (Scott Lurndal) - 2025-09-09 14:45 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#122694

On 05/09/2025 16:08, Scott Lurndal wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 04.09.2025 17:57, boltar@caprica.universe wrote:
>>> On Thu, 4 Sep 2025 12:40:37 +0200
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> gabbled:
>>>> On 04.09.2025 10:36, boltar@caprica.universe wrote:
>>>>> I'd love to hear his opinion of the designed-by-committee syntatic
>>>>> horror that is modern C++.
>>>>
>>>> You are probably speaking about the newer C++ standards, and also
>>>> not about the "C" contribution to the "syntactic horror". Right?
>>>
>>> C's syntax might not be the best, but its relatively simple. C++ syntax is
>>> a dogs dinner and gets worse everytime the steering committee farts out a
>>> new version every 3 years with increasingly niche and obscure functionality.
>>> Some C++ code now is virtually unparsable by the human eye and a lot of the
>>> new crap are meta keywords that are compiler directives or hints rather than
>>> code that actually does something. eg:
>>>
>>> swappable
>>> swappable_with 	
>>> destructible 	
>>> constructible_from 	
>>> default_initializable
>>>
>>
>> Thanks for clarifying. - I stopped my professional use of C++ with
>> this millennium. The last standard that came to my attention was
>> something like "C++0x/C++11" (IIRC, with move semantics, and some
>> such). While I understand the motivation for introduction of such
>> things I already found the syntax, the implications on readability,
>> and the complexity a problem back then
> 
> Nobody is required to actually use all that cruft.  It is still
> possible to write C with classes using even the most modern C++
> suite.

Indeed.

Much of those sorts of things are useful for writing high-performance 
general purpose containers and other such flexible libraries.  For most 
user code, you don't need more than a fraction of what C++ provides (but 
/which/ fraction will depend on the user).

[toc] | [prev] | [next] | [standalone]

#122695

On Fri, 5 Sep 2025 16:51:32 +0200
David Brown <david.brown@hesbynett.no> gabbled:
>On 05/09/2025 16:08, Scott Lurndal wrote:
>> Nobody is required to actually use all that cruft.  It is still
>> possible to write C with classes using even the most modern C++
>> suite.
>
>Indeed.
>
>Much of those sorts of things are useful for writing high-performance 
>general purpose containers and other such flexible libraries.  For most 
>user code, you don't need more than a fraction of what C++ provides (but 
>/which/ fraction will depend on the user).

If only life were that simple. If it exists someone WILL use it and if you're
a professional dev you'll be expected to know it and be able to maintain the
code. Whats more, job interviews often throw in questions or even code writing
exercises about the latest and greatest C++ functionality. Its no good only 
knowing up to C++17 if you're going to an interview in 2025.

Of course it works the other way too - a C++ dev who knows everything about
concepts and co-routines but doesn't know one end of a pointer from the other
won't be getting many jobs either.

[toc] | [prev] | [next] | [standalone]

#122697

On Fri, 2025-09-05 at 16:51 +0200, David Brown wrote:
> On 05/09/2025 16:08, Scott Lurndal wrote:
> > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> > > On 04.09.2025 17:57, boltar@caprica.universe wrote:
> > > > On Thu, 4 Sep 2025 12:40:37 +0200
> > > > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> gabbled:
> > > > > On 04.09.2025 10:36, boltar@caprica.universe wrote:
> > > > > > I'd love to hear his opinion of the designed-by-committee syntatic
> > > > > > horror that is modern C++.
> > > > > 
> > > > > You are probably speaking about the newer C++ standards, and also
> > > > > not about the "C" contribution to the "syntactic horror". Right?
> > > > 
> > > > C's syntax might not be the best, but its relatively simple. C++ syntax is
> > > > a dogs dinner and gets worse everytime the steering committee farts out a
> > > > new version every 3 years with increasingly niche and obscure functionality.
> > > > Some C++ code now is virtually unparsable by the human eye and a lot of the
> > > > new crap are meta keywords that are compiler directives or hints rather than
> > > > code that actually does something. eg:
> > > > 
> > > > swappable
> > > > swappable_with 	
> > > > destructible 	
> > > > constructible_from 	
> > > > default_initializable
> > > > 
> > > 
> > > Thanks for clarifying. - I stopped my professional use of C++ with
> > > this millennium. The last standard that came to my attention was
> > > something like "C++0x/C++11" (IIRC, with move semantics, and some
> > > such). While I understand the motivation for introduction of such
> > > things I already found the syntax, the implications on readability,
> > > and the complexity a problem back then
> > 
> > Nobody is required to actually use all that cruft.  It is still
> > possible to write C with classes using even the most modern C++
> > suite.
> 
> Indeed.
> 
> Much of those sorts of things are useful for writing high-performance 
> general purpose containers and other such flexible libraries.  For most 
> user code, you don't need more than a fraction of what C++ provides (but 
> /which/ fraction will depend on the user).

Using newer features of C++ makes the user codes practically less portable and
less maintainable, particularly when less new codes are written in C++ and when 
there are many ways to implement the 'new feature'.

[toc] | [prev] | [next] | [standalone]

#122698

On Fri, 2025-09-05 at 16:51 +0200, David Brown wrote:
> On 05/09/2025 16:08, Scott Lurndal wrote:
> > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> > > On 04.09.2025 17:57, boltar@caprica.universe wrote:
> > > > On Thu, 4 Sep 2025 12:40:37 +0200
> > > > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> gabbled:
> > > > > On 04.09.2025 10:36, boltar@caprica.universe wrote:
> > > > > > I'd love to hear his opinion of the designed-by-committee syntatic
> > > > > > horror that is modern C++.
> > > > > 
> > > > > You are probably speaking about the newer C++ standards, and also
> > > > > not about the "C" contribution to the "syntactic horror". Right?
> > > > 
> > > > C's syntax might not be the best, but its relatively simple. C++ syntax is
> > > > a dogs dinner and gets worse everytime the steering committee farts out a
> > > > new version every 3 years with increasingly niche and obscure functionality.
> > > > Some C++ code now is virtually unparsable by the human eye and a lot of the
> > > > new crap are meta keywords that are compiler directives or hints rather than
> > > > code that actually does something. eg:
> > > > 
> > > > swappable
> > > > swappable_with 	
> > > > destructible 	
> > > > constructible_from 	
> > > > default_initializable
> > > > 
> > > 
> > > Thanks for clarifying. - I stopped my professional use of C++ with
> > > this millennium. The last standard that came to my attention was
> > > something like "C++0x/C++11" (IIRC, with move semantics, and some
> > > such). While I understand the motivation for introduction of such
> > > things I already found the syntax, the implications on readability,
> > > and the complexity a problem back then
> > 
> > Nobody is required to actually use all that cruft.  It is still
> > possible to write C with classes using even the most modern C++
> > suite.
> 
> Indeed.
> 
> Much of those sorts of things are useful for writing high-performance 
> general purpose containers and other such flexible libraries.  For most 
> user code, you don't need more than a fraction of what C++ provides (but 
> /which/ fraction will depend on the user).

Using newer features of C++ makes the user codes practically less portable and
less maintainable, particularly when less new codes are written in C++ and when 
there are many ways to implement the 'new feature'.

[toc] | [prev] | [next] | [standalone]

#122707

On Fri, 5 Sep 2025 16:51:32 +0200
David Brown <david.brown@hesbynett.no> wrote:

> On 05/09/2025 16:08, Scott Lurndal wrote:
> > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:  
> >> On 04.09.2025 17:57, boltar@caprica.universe wrote:  
> >>> On Thu, 4 Sep 2025 12:40:37 +0200
> >>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> gabbled:  
> >>>> On 04.09.2025 10:36, boltar@caprica.universe wrote:  
> >>>>> I'd love to hear his opinion of the designed-by-committee
> >>>>> syntatic horror that is modern C++.  
> >>>>
> >>>> You are probably speaking about the newer C++ standards, and also
> >>>> not about the "C" contribution to the "syntactic horror". Right?
> >>>>  
> >>>
> >>> C's syntax might not be the best, but its relatively simple. C++
> >>> syntax is a dogs dinner and gets worse everytime the steering
> >>> committee farts out a new version every 3 years with increasingly
> >>> niche and obscure functionality. Some C++ code now is virtually
> >>> unparsable by the human eye and a lot of the new crap are meta
> >>> keywords that are compiler directives or hints rather than code
> >>> that actually does something. eg:
> >>>
> >>> swappable
> >>> swappable_with 	
> >>> destructible 	
> >>> constructible_from 	
> >>> default_initializable
> >>>  
> >>
> >> Thanks for clarifying. - I stopped my professional use of C++ with
> >> this millennium. The last standard that came to my attention was
> >> something like "C++0x/C++11" (IIRC, with move semantics, and some
> >> such). While I understand the motivation for introduction of such
> >> things I already found the syntax, the implications on readability,
> >> and the complexity a problem back then  
> > 
> > Nobody is required to actually use all that cruft.  It is still
> > possible to write C with classes using even the most modern C++
> > suite.  
> 
> Indeed.
> 
> Much of those sorts of things are useful for writing high-performance 
> general purpose containers and other such flexible libraries. 

Disagreed.
The syntactic innovations that cause "modern C++" to look as different
language from both original "C with classes" and from following "C with
classes and templates" are:
Major:
1. Lambda expressions 
2. Uniform initialization
3. Range-based for loop
4. Attributes
Minor:
1. New meaning of auto.

All of those were introduced in C++11.

More recent additions with syntax that looks alien are:
1. Concepts 
2. Three-way comparison
Happily, those are more specialized and as such less pervasive.


> For
> most user code, you don't need more than a fraction of what C++
> provides (but /which/ fraction will depend on the user).
> 

Statements like that apply to just about any language or framework.
Which makes them useless.

comp.lang.c removed

[toc] | [prev] | [next] | [standalone]

#122708

On 07/09/2025 10:16, Michael S wrote:
> On Fri, 5 Sep 2025 16:51:32 +0200
> David Brown <david.brown@hesbynett.no> wrote:
> 
>> On 05/09/2025 16:08, Scott Lurndal wrote:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>> On 04.09.2025 17:57, boltar@caprica.universe wrote:
>>>>> On Thu, 4 Sep 2025 12:40:37 +0200
>>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> gabbled:
>>>>>> On 04.09.2025 10:36, boltar@caprica.universe wrote:
>>>>>>> I'd love to hear his opinion of the designed-by-committee
>>>>>>> syntatic horror that is modern C++.
>>>>>>
>>>>>> You are probably speaking about the newer C++ standards, and also
>>>>>> not about the "C" contribution to the "syntactic horror". Right?
>>>>>>   
>>>>>
>>>>> C's syntax might not be the best, but its relatively simple. C++
>>>>> syntax is a dogs dinner and gets worse everytime the steering
>>>>> committee farts out a new version every 3 years with increasingly
>>>>> niche and obscure functionality. Some C++ code now is virtually
>>>>> unparsable by the human eye and a lot of the new crap are meta
>>>>> keywords that are compiler directives or hints rather than code
>>>>> that actually does something. eg:
>>>>>
>>>>> swappable
>>>>> swappable_with 	
>>>>> destructible 	
>>>>> constructible_from 	
>>>>> default_initializable
>>>>>   
>>>>
>>>> Thanks for clarifying. - I stopped my professional use of C++ with
>>>> this millennium. The last standard that came to my attention was
>>>> something like "C++0x/C++11" (IIRC, with move semantics, and some
>>>> such). While I understand the motivation for introduction of such
>>>> things I already found the syntax, the implications on readability,
>>>> and the complexity a problem back then
>>>
>>> Nobody is required to actually use all that cruft.  It is still
>>> possible to write C with classes using even the most modern C++
>>> suite.
>>
>> Indeed.
>>
>> Much of those sorts of things are useful for writing high-performance
>> general purpose containers and other such flexible libraries.
> 
> Disagreed.
> The syntactic innovations that cause "modern C++" to look as different
> language from both original "C with classes" and from following "C with
> classes and templates" are:
> Major:
> 1. Lambda expressions
> 2. Uniform initialization
> 3. Range-based for loop
> 4. Attributes
> Minor:
> 1. New meaning of auto.
> 
> All of those were introduced in C++11.
> 

Yes, these are all new in C++11 onwards.  And I agree that they change 
the way C++ looks - and that these are all becoming quite pervasive in 
"normal" C++ beyond "C with classes".

> More recent additions with syntax that looks alien are:
> 1. Concepts
> 2. Three-way comparison
> Happily, those are more specialized and as such less pervasive.
> 

I was thinking more along those lines - and things like fold 
expressions, complicated "noeexcept" expressions, template-template 
parameters, and moving and forwarding parameters.

But of course these things are a matter of opinion and subjective uses 
and experience.  And there is always the tendency for some of new things 
to appear "alien" but gradually become part of common usage.

> 
>> For
>> most user code, you don't need more than a fraction of what C++
>> provides (but /which/ fraction will depend on the user).
>>
> 
> Statements like that apply to just about any language or framework.
> Which makes them useless.
> 
> comp.lang.c removed
> 

C would be an example of a language where you /can/ learn the solid 
majority of it, and people use a large proportion of its features in 
everyday coding.

When I used Borland Pascal, I knew pretty much all of the language. 
When I used BASIC on a variety of 1980's computers, I knew all every 
statement and expression in the languages.  When I started with 
microcontrollers, I knew every assembly instruction and cpu register, 
and knew most of the peripherals in detail.  I don't imagine I am alone 
in having that kind of near-complete knowledge of older and smaller 
languages and systems.

It is certainly true, however, that languages and systems have grown 
massively over the years, and for many modern languages it would be 
completely infeasible for one person to really understand and use more 
than a small part.  But you still have a chance for some newer languages 
like Zig or Nim, which make a point of trying to be small enough that 
they don't have features that are not needed on a regular basis.

[toc] | [prev] | [next] | [standalone]

#122709

On Sun, 2025-09-07 at 12:08 +0200, David Brown wrote:
> On 07/09/2025 10:16, Michael S wrote:
> > On Fri, 5 Sep 2025 16:51:32 +0200
> > David Brown <david.brown@hesbynett.no> wrote:
> > 
> > > On 05/09/2025 16:08, Scott Lurndal wrote:
> > > > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> > > > > On 04.09.2025 17:57, boltar@caprica.universe wrote:
> > > > > > On Thu, 4 Sep 2025 12:40:37 +0200
> > > > > > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> gabbled:
> > > > > > > On 04.09.2025 10:36, boltar@caprica.universe wrote:
> > > > > > > > I'd love to hear his opinion of the designed-by-committee
> > > > > > > > syntatic horror that is modern C++.
> > > > > > > 
> > > > > > > You are probably speaking about the newer C++ standards, and also
> > > > > > > not about the "C" contribution to the "syntactic horror". Right?
> > > > > > >   
> > > > > > 
> > > > > > C's syntax might not be the best, but its relatively simple. C++
> > > > > > syntax is a dogs dinner and gets worse everytime the steering
> > > > > > committee farts out a new version every 3 years with increasingly
> > > > > > niche and obscure functionality. Some C++ code now is virtually
> > > > > > unparsable by the human eye and a lot of the new crap are meta
> > > > > > keywords that are compiler directives or hints rather than code
> > > > > > that actually does something. eg:
> > > > > > 
> > > > > > swappable
> > > > > > swappable_with 	
> > > > > > destructible 	
> > > > > > constructible_from 	
> > > > > > default_initializable
> > > > > >   
> > > > > 
> > > > > Thanks for clarifying. - I stopped my professional use of C++ with
> > > > > this millennium. The last standard that came to my attention was
> > > > > something like "C++0x/C++11" (IIRC, with move semantics, and some
> > > > > such). While I understand the motivation for introduction of such
> > > > > things I already found the syntax, the implications on readability,
> > > > > and the complexity a problem back then
> > > > 
> > > > Nobody is required to actually use all that cruft.  It is still
> > > > possible to write C with classes using even the most modern C++
> > > > suite.
> > > 
> > > Indeed.
> > > 
> > > Much of those sorts of things are useful for writing high-performance
> > > general purpose containers and other such flexible libraries.
> > 
> > Disagreed.
> > The syntactic innovations that cause "modern C++" to look as different
> > language from both original "C with classes" and from following "C with
> > classes and templates" are:
> > Major:
> > 1. Lambda expressions
> > 2. Uniform initialization
> > 3. Range-based for loop
> > 4. Attributes
> > Minor:
> > 1. New meaning of auto.
> > 
> > All of those were introduced in C++11.
> > 
> 
> Yes, these are all new in C++11 onwards.  And I agree that they change 
> the way C++ looks - and that these are all becoming quite pervasive in 
> "normal" C++ beyond "C with classes".
> 
> > More recent additions with syntax that looks alien are:
> > 1. Concepts
> > 2. Three-way comparison
> > Happily, those are more specialized and as such less pervasive.
> > 
> 
> I was thinking more along those lines - and things like fold 
> expressions, complicated "noeexcept" expressions, template-template 
> parameters, and moving and forwarding parameters.
> 
> But of course these things are a matter of opinion and subjective uses 
> and experience.  And there is always the tendency for some of new things 
> to appear "alien" but gradually become part of common usage.

That the last sentence is one-sided wish.
Many 'new things' (not all. some, typically small, are good) are involving 
doing the same thing in 'standardized different' way while every field has their own
good problem solving logic. That is just one aspect of the problem of redundency.

Another thing is 'C++' seems always aims at 'small' things that can be done
otherwise. E.g. the basic array things (important). Can std::vector, std::array 
be used widely enough, for system programming, even in C++std library itself?
The needs for 'vector'(math)/matrix has kept increasing.
The demand of graphics/sound is always there. And, now, there are 'AI' stuff.
C++ dare to touch these topics? No, always things like some piece of code doing 
this way will be 'good'....

'C++' is ultimately defined by C++ commitee members.
If it decided to shoot its own feet... It is still C++.
So, you are right, choose whatever is needed (but that is a problem for C++
beginners).

> > 
> > > For
> > > most user code, you don't need more than a fraction of what C++
> > > provides (but /which/ fraction will depend on the user).
> > > 
> > 
> > Statements like that apply to just about any language or framework.
> > Which makes them useless.
> > 
> > comp.lang.c removed
> > 
> 
> C would be an example of a language where you /can/ learn the solid 
> majority of it, and people use a large proportion of its features in 
> everyday coding.
> 
> When I used Borland Pascal, I knew pretty much all of the language. 
> When I used BASIC on a variety of 1980's computers, I knew all every 
> statement and expression in the languages.  When I started with 
> microcontrollers, I knew every assembly instruction and cpu register, 
> and knew most of the peripherals in detail.  I don't imagine I am alone 
> in having that kind of near-complete knowledge of older and smaller 
> languages and systems.
> 
> It is certainly true, however, that languages and systems have grown 
> massively over the years, and for many modern languages it would be 
> completely infeasible for one person to really understand and use more 
> than a small part.  But you still have a chance for some newer languages 
> like Zig or Nim, which make a point of trying to be small enough that 
> they don't have features that are not needed on a regular basis.
> 

[toc] | [prev] | [next] | [standalone]

#122710

On Sun, 7 Sep 2025 12:08:08 +0200
David Brown <david.brown@hesbynett.no> gabbled:
>On 07/09/2025 10:16, Michael S wrote:
>> Statements like that apply to just about any language or framework.
>> Which makes them useless.
>> 
>> comp.lang.c removed
>> 
>
>C would be an example of a language where you /can/ learn the solid 
>majority of it, and people use a large proportion of its features in 
>everyday coding.
>
>When I used Borland Pascal, I knew pretty much all of the language. 
>When I used BASIC on a variety of 1980's computers, I knew all every 
>statement and expression in the languages.  When I started with 
>microcontrollers, I knew every assembly instruction and cpu register, 

Modern x86 is a good example of a CPU that is simply not possible for one
person to know and understand all the opcodes. Sometimes I wonder if even
the compilers know them all given some of the assembler I've seen being
generated for it. gcc for example seems to have a strange aversion to ever
using the FPU opcodes.

[toc] | [prev] | [next] | [standalone]

#122715

On 07/09/2025 16:42, boltar@caprica.universe wrote:
> On Sun, 7 Sep 2025 12:08:08 +0200
> David Brown <david.brown@hesbynett.no> gabbled:
>> On 07/09/2025 10:16, Michael S wrote:
>>> Statements like that apply to just about any language or framework.
>>> Which makes them useless.
>>>
>>> comp.lang.c removed
>>>
>>
>> C would be an example of a language where you /can/ learn the solid 
>> majority of it, and people use a large proportion of its features in 
>> everyday coding.
>>
>> When I used Borland Pascal, I knew pretty much all of the language. 
>> When I used BASIC on a variety of 1980's computers, I knew all every 
>> statement and expression in the languages.  When I started with 
>> microcontrollers, I knew every assembly instruction and cpu register, 
> 
> Modern x86 is a good example of a CPU that is simply not possible for one
> person to know and understand all the opcodes.

I have a few old x86 assembly books on my bookshelf, and an Intel i486 
reference manual - but I gave up after that.  I am quite fluent at 
reading x86 assembly (thanks mostly to godbolt.org), but have no plans 
for trying to understand it all or - even worse - understand what is 
fast or slow on a given x86 device.

> Sometimes I wonder if even
> the compilers know them all given some of the assembler I've seen being
> generated for it. gcc for example seems to have a strange aversion to ever
> using the FPU opcodes.
> 

I haven't needed to use floating point on x86 in any kind of 
efficiency-critical situation, so I can't give useful suggestions there. 
  But I have used gcc and floating point on a few embedded targets.  One 
thing that I often see there is that on microcontrollers, floating point 
units can often have incomplete IEEE support in instructions.  This can 
mean that when you ask for, say, a square root, you get a library call. 
First the library function checks for and handles NaNs, infinities, and 
other awkward values, before it can use a square root opcode to do the 
work for normal values.  Using "-ffast-math" for that kind of target can 
make an enormous difference because it simplifies the code - it assumes 
you have only normal floating point values, that operations are 
associative like they would be in real mathematics, and so on.  Perhaps 
you would see similar benefits from "-ffast-math" on gcc?

The other thing you see with gcc on x86 is that code is made to work on 
a very large range of devices.  If you use "-march=native", or give it 
an explicit "-march" flag, gcc is much freer to use SIMD and other 
opcodes that are not supported on all x86 targets.

I can't say if that would make a noticeable difference for you or not.

[toc] | [prev] | [next] | [standalone]

#122711

Michael S <already5chosen@yahoo.com> writes:
>On Fri, 5 Sep 2025 16:51:32 +0200
>David Brown <david.brown@hesbynett.no> wrote:
>
>> On 05/09/2025 16:08, Scott Lurndal wrote:
>> > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:  
>> >> On 04.09.2025 17:57, boltar@caprica.universe wrote:  
>> >>> On Thu, 4 Sep 2025 12:40:37 +0200
>> >>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> gabbled:  
>> >>>> On 04.09.2025 10:36, boltar@caprica.universe wrote:  
>> >>>>> I'd love to hear his opinion of the designed-by-committee
>> >>>>> syntatic horror that is modern C++.  
>> >>>>
>> >>>> You are probably speaking about the newer C++ standards, and also
>> >>>> not about the "C" contribution to the "syntactic horror". Right?
>> >>>>  
>> >>>
>> >>> C's syntax might not be the best, but its relatively simple. C++
>> >>> syntax is a dogs dinner and gets worse everytime the steering
>> >>> committee farts out a new version every 3 years with increasingly
>> >>> niche and obscure functionality. Some C++ code now is virtually
>> >>> unparsable by the human eye and a lot of the new crap are meta
>> >>> keywords that are compiler directives or hints rather than code
>> >>> that actually does something. eg:
>> >>>
>> >>> swappable
>> >>> swappable_with 	
>> >>> destructible 	
>> >>> constructible_from 	
>> >>> default_initializable
>> >>>  
>> >>
>> >> Thanks for clarifying. - I stopped my professional use of C++ with
>> >> this millennium. The last standard that came to my attention was
>> >> something like "C++0x/C++11" (IIRC, with move semantics, and some
>> >> such). While I understand the motivation for introduction of such
>> >> things I already found the syntax, the implications on readability,
>> >> and the complexity a problem back then  
>> > 
>> > Nobody is required to actually use all that cruft.  It is still
>> > possible to write C with classes using even the most modern C++
>> > suite.  
>> 
>> Indeed.
>> 
>> Much of those sorts of things are useful for writing high-performance 
>> general purpose containers and other such flexible libraries. 
>
>Disagreed.
>The syntactic innovations that cause "modern C++" to look as different
>language from both original "C with classes" and from following "C with
>classes and templates" are:
>Major:
>1. Lambda expressions 

  Syntactic sugar.

>2. Uniform initialization

  Syntactic sugar.

>3. Range-based for loop

  Syntactic sugar.

>4. Attributes

  Available through compiler-specific directives for decades,
but generally rarely useful.

>Minor:
>1. New meaning of auto.

  Doesn't increase readability, IMO.

[toc] | [prev] | [next] | [standalone]

#122712

On Sun, 07 Sep 2025 15:30:34 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
>Michael S <already5chosen@yahoo.com> writes:
>>1. Lambda expressions 
>
>  Syntactic sugar.

They can make code a bit more compact and easier to follow.

>>1. New meaning of auto.
>
>  Doesn't increase readability, IMO.

Devs using auto everywhere really boils my piss sometimes. If I wanted a
language where I can't tell what type a variable is without searching through 
the code or using an IDE I'd use python. Its bad enough with templates but
at least they have a useful function.

[toc] | [prev] | [next] | [standalone]

#122731

boltar@caprica.universe <boltar@caprica.universe> wrote at 16:00 this Sunday (GMT):
> On Sun, 07 Sep 2025 15:30:34 GMT
> scott@slp53.sl.home (Scott Lurndal) gabbled:
>>Michael S <already5chosen@yahoo.com> writes:
>>>1. Lambda expressions 
>>
>>  Syntactic sugar.
>
> They can make code a bit more compact and easier to follow.

That is the definition of syntax sugar, yeah.

>>>1. New meaning of auto.
>>
>>  Doesn't increase readability, IMO.
>
> Devs using auto everywhere really boils my piss sometimes. If I wanted a
> language where I can't tell what type a variable is without searching through 
> the code or using an IDE I'd use python. Its bad enough with templates but
> at least they have a useful function.


JS is way worse I think.
-- 
user <candycane> is generated from /dev/urandom

[toc] | [prev] | [next] | [standalone]

#122700

On 9/5/2025 9:08 AM, Scott Lurndal wrote:
...
>> Thanks for clarifying. - I stopped my professional use of C++ with
>> this millennium. The last standard that came to my attention was
>> something like "C++0x/C++11" (IIRC, with move semantics, and some
>> such). While I understand the motivation for introduction of such
>> things I already found the syntax, the implications on readability,
>> and the complexity a problem back then
> 
> Nobody is required to actually use all that cruft.  It is still
> possible to write C with classes using even the most modern C++
> suite.

Which I do with my 450,000 lines of C++ code plus the basic collections 
in the STL.

I am still moving my 800,000 lines of F77 to C++ using this strategy also.

Lynn

[toc] | [prev] | [next] | [standalone]

#122703

On 05.09.2025 16:08, Scott Lurndal wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 04.09.2025 17:57, boltar@caprica.universe wrote:
>>> On Thu, 4 Sep 2025 12:40:37 +0200
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> gabbled:
>>>> On 04.09.2025 10:36, boltar@caprica.universe wrote:
>>>>> I'd love to hear his opinion of the designed-by-committee syntatic
>>>>> horror that is modern C++.
>>>>
>>>> You are probably speaking about the newer C++ standards, and also
>>>> not about the "C" contribution to the "syntactic horror". Right?
>>>
>>> C's syntax might not be the best, but its relatively simple. C++ syntax is
>>> a dogs dinner and gets worse everytime the steering committee farts out a 
>>> new version every 3 years with increasingly niche and obscure functionality.
>>> Some C++ code now is virtually unparsable by the human eye and a lot of the
>>> new crap are meta keywords that are compiler directives or hints rather than 
>>> code that actually does something. eg:
>>>
>>> swappable
>>> swappable_with 	
>>> destructible 	
>>> constructible_from 	
>>> default_initializable
>>>
>>
>> Thanks for clarifying. - I stopped my professional use of C++ with
>> this millennium. The last standard that came to my attention was
>> something like "C++0x/C++11" (IIRC, with move semantics, and some
>> such). While I understand the motivation for introduction of such
>> things I already found the syntax, the implications on readability,
>> and the complexity a problem back then
> 
> Nobody is required to actually use all that cruft.  It is still
> possible to write C with classes using even the most modern C++
> suite.

I don't think this statement addresses the key point of the poster
in any substantial way. You can also write your programs in Modula
and have then got rid even of the remaining "C" "cruft" (as it had
been formulated).

The point is that if you learn C++ you typically won't buy a book
of the year's 1990 state of play. And if you're confronted with C++
software created from other people you can't just ignore what they
used as feature set; and my experience is that especially younger
folks use what's provided as features in any language.

Any isolated individual is not the measure of things when speaking
about "syntax horrors"; neither as producer nor as consumer of the
respective software or programming language "cruft". The post made
a (valid) statement about language design and language evolution.

Janis

[toc] | [prev] | [next] | [standalone]

#122701

On 2025-09-04 23:42, Janis Papanagnou wrote:
...> WRT C's contribution I agree that it's comparable simple, but still
> contributes not insignificantly to the "syntax horror". It might be
> more an issue for folks who are also used to non-"C"-like languages.

As someone who's second computer language was APL, which I loved, I
reserve the concept of "syntax horror" for things like COBOL. I've heard
that one of the concepts behind the design of COBOL is that it should
allow managers to write programs, obviating the need for specialized
programmers. I've heard the same thing about assembly language, when it
first came out (I heard it third hand - I'm not quite that old).

[toc] | [prev] | [next] | [standalone]

#122702

On Fri, 05 Sep 2025 17:34:34 -0400, James Kuyper wrote:

> On 2025-09-04 23:42, Janis Papanagnou wrote:
> ...> WRT C's contribution I agree that it's comparable simple, but still
>> contributes not insignificantly to the "syntax horror". It might be
>> more an issue for folks who are also used to non-"C"-like languages.
> 
> As someone who's second computer language was APL, which I loved, I
> reserve the concept of "syntax horror" for things like COBOL. I've heard
> that one of the concepts behind the design of COBOL is that it should
> allow managers to write programs, obviating the need for specialized
> programmers. 

While CODASYL might have claimed to business that COBOL would let managers
write code, that was never the actual case. What the COBOL syntax did was
permit /programmers/ to write code that mirrored the business processes
that the front-line staff performed. If an accountant computed sales tax
by multiplying the total cost by a fixed percent, the programmer could easily
code that as
  MULTIPLY TOTAL-COST BY FIXED_PERCENT GIVING SALES-TAX.
and the front-line staff could confirm (or deny) that /that/ was the process
they followed.

While wordy, COBOL is still a Turing-complete language, and anything that you
can do in C, you can do (granted, not as susinctly) in COBOL.

> I've heard the same thing about assembly language, when it
> first came out (I heard it third hand - I'm not quite that old).

AFAICT, Assembly language was never touted as a language that managers could write.
Having written a lot of Assembly in my time, I can safely say that only the managers
that started off as Assembly programmers could read and write Assembly code.

-- 
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.

[toc] | [prev] | [next] | [standalone]

#122704

On 05.09.2025 23:55, Lew Pitcher wrote:
> On Fri, 05 Sep 2025 17:34:34 -0400, James Kuyper wrote:
> 
>> On 2025-09-04 23:42, Janis Papanagnou wrote:
>> ...> WRT C's contribution I agree that it's comparable simple, but still
>>> contributes not insignificantly to the "syntax horror". It might be
>>> more an issue for folks who are also used to non-"C"-like languages.
>>
>> As someone who's second computer language was APL, which I loved, I
>> reserve the concept of "syntax horror" for things like COBOL.

Well, on my scale INTERCAL is on that far end. And if you ask me where
I'd sort in COBOL or C - I'm not that sure that COBOL would be closer;
you can at least write readable code in COBOL.

>> [...]
> 
> While CODASYL might have claimed to business that COBOL would let managers
> write code, that was never the actual case. What the COBOL syntax did was
> permit /programmers/ to write code that mirrored the business processes
> that the front-line staff performed. If an accountant computed sales tax
> by multiplying the total cost by a fixed percent, the programmer could easily
> code that as
>   MULTIPLY TOTAL-COST BY FIXED_PERCENT GIVING SALES-TAX.

Or something like

  COMPUTE  SALES-TAX = TOTAL-COST * FIXED-PERCENT

(with a syntax that might mollify James a bit).

> and the front-line staff could confirm (or deny) that /that/ was the process
> they followed.
> 
> While wordy, COBOL is still a Turing-complete language, and anything that you
> can do in C, you can do (granted, not as susinctly) in COBOL.

Janis

>> [...]
> [...]

[toc] | [prev] | [next] | [standalone]

#122705

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>On Fri, 05 Sep 2025 17:34:34 -0400, James Kuyper wrote:
>
>> On 2025-09-04 23:42, Janis Papanagnou wrote:
>> ...> WRT C's contribution I agree that it's comparable simple, but still
>>> contributes not insignificantly to the "syntax horror". It might be
>>> more an issue for folks who are also used to non-"C"-like languages.
>> 
>> As someone who's second computer language was APL, which I loved, I
>> reserve the concept of "syntax horror" for things like COBOL. I've heard
>> that one of the concepts behind the design of COBOL is that it should
>> allow managers to write programs, obviating the need for specialized
>> programmers. 
>
>While CODASYL might have claimed to business that COBOL would let managers
>write code, that was never the actual case. What the COBOL syntax did was
>permit /programmers/ to write code that mirrored the business processes
>that the front-line staff performed. If an accountant computed sales tax
>by multiplying the total cost by a fixed percent, the programmer could easily
>code that as
>  MULTIPLY TOTAL-COST BY FIXED_PERCENT GIVING SALES-TAX.
>and the front-line staff could confirm (or deny) that /that/ was the process
>they followed.
>
>While wordy, COBOL is still a Turing-complete language, and anything that you
>can do in C, you can do (granted, not as susinctly) in COBOL.

With certain caveats.  I.e.  the COBOL compiler needs some way to link
to external assembler functions.,

Burroughs COBOL 68 compiler had the phrase "ENTER SYMBOLIC.".  Source
lines after that were treated as embedded assembler until "LEAVE SYMBOLIC.".

The MCP Disk Defragmenter utility was written in COBOL 68.

The COBOL 74 compiler supported linking (binding) independently compiled modules
into a single executable, and the ICM was standard across all supported
compilers.   Most often COBOL74 would call BPL (Burroughs Programming Language)
functions to access MCP facilities not supported natively by COBOL syntax.

[toc] | [prev] | [next] | [standalone]

#122706

On Sat, 06 Sep 2025 17:46:54 +0000, Scott Lurndal wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>On Fri, 05 Sep 2025 17:34:34 -0400, James Kuyper wrote:
>>
>>> On 2025-09-04 23:42, Janis Papanagnou wrote:
>>> ...> WRT C's contribution I agree that it's comparable simple, but still
>>>> contributes not insignificantly to the "syntax horror". It might be
>>>> more an issue for folks who are also used to non-"C"-like languages.
>>> 
>>> As someone who's second computer language was APL, which I loved, I
>>> reserve the concept of "syntax horror" for things like COBOL. I've heard
>>> that one of the concepts behind the design of COBOL is that it should
>>> allow managers to write programs, obviating the need for specialized
>>> programmers. 
>>
>>While CODASYL might have claimed to business that COBOL would let managers
>>write code, that was never the actual case. What the COBOL syntax did was
>>permit /programmers/ to write code that mirrored the business processes
>>that the front-line staff performed. If an accountant computed sales tax
>>by multiplying the total cost by a fixed percent, the programmer could easily
>>code that as
>>  MULTIPLY TOTAL-COST BY FIXED_PERCENT GIVING SALES-TAX.
>>and the front-line staff could confirm (or deny) that /that/ was the process
>>they followed.
>>
>>While wordy, COBOL is still a Turing-complete language, and anything that you
>>can do in C, you can do (granted, not as susinctly) in COBOL.
> 
> With certain caveats.  I.e.  the COBOL compiler needs some way to link
> to external assembler functions.,

The bog-standard COBOL CALL verb suffices for that, along with a suitable
linkage editor or linking loader
https://www.ibm.com/docs/en/cobol-zos/6.3.0?topic=statements-call-statement

> Burroughs COBOL 68 compiler had the phrase "ENTER SYMBOLIC.".  Source
> lines after that were treated as embedded assembler until "LEAVE SYMBOLIC.".

> The MCP Disk Defragmenter utility was written in COBOL 68.
> 
> The COBOL 74 compiler supported linking (binding) independently compiled modules
> into a single executable, and the ICM was standard across all supported
> compilers.   Most often COBOL74 would call BPL (Burroughs Programming Language)
> functions to access MCP facilities not supported natively by COBOL syntax.

The last COBOL I worked with supported both static and dynamic load. IBM OS390
was like that (I retired before I got to zOS)

-- 
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.

[toc] | [prev] | [next] | [standalone]

#122723

On Sat, 6 Sep 2025 18:38:31 -0000 (UTC), Lew Pitcher wrote:

> The bog-standard COBOL CALL verb suffices for that, along with a
> suitable linkage editor or linking loader
> https://www.ibm.com/docs/en/cobol-zos/6.3.0?topic=statements-call-statement

No support for variadic subroutines, I see ...

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web