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

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

"Trip report: June 2025 ISO C++ standards meeting (Sofia, Bulgaria)" by Herb Sutter

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

Contents

  "Trip report: June 2025 ISO C++ standards meeting (Sofia, Bulgaria)" by Herb Sutter Lynn McGuire <lynnmcguire5@gmail.com> - 2025-06-22 19:37 -0500
    Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, Bulgaria)" Muttley@dastardlyhq.com - 2025-06-25 08:47 +0000
      Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, Bulgaria)" Michael S <already5chosen@yahoo.com> - 2025-06-25 16:48 +0300
        Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, Muttley@dastardlyhq.com - 2025-06-25 14:59 +0000
          Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, scott@slp53.sl.home (Scott Lurndal) - 2025-06-25 15:37 +0000
            Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, Muttley@dastardlyhq.com - 2025-06-25 15:52 +0000
              Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, David Brown <david.brown@hesbynett.no> - 2025-06-25 21:03 +0200
                Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, scott@slp53.sl.home (Scott Lurndal) - 2025-06-25 20:49 +0000
                Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, Muttley@DastardlyHQ.org - 2025-06-26 08:17 +0000
                  Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, David Brown <david.brown@hesbynett.no> - 2025-06-26 15:41 +0200
                    Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, Muttley@DastardlyHQ.org - 2025-06-26 16:05 +0000
                    Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, wij <wyniijj5@gmail.com> - 2025-06-27 12:56 +0800
                      Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, David Brown <david.brown@hesbynett.no> - 2025-06-27 10:53 +0200
                        Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, wij <wyniijj5@gmail.com> - 2025-06-28 15:16 +0800
                          Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, David Brown <david.brown@hesbynett.no> - 2025-06-28 17:09 +0200
                            Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, wij <wyniijj5@gmail.com> - 2025-06-29 01:24 +0800
                              Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, David Brown <david.brown@hesbynett.no> - 2025-06-28 21:11 +0200
                      Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, Muttley@DastardlyHQ.org - 2025-06-27 12:21 +0000
                        Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-27 11:30 -0700
                        Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, wij <wyniijj5@gmail.com> - 2025-06-28 14:58 +0800
                          Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, Muttley@dastardlyhq.com - 2025-06-28 15:37 +0000
                            Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, wij <wyniijj5@gmail.com> - 2025-06-29 01:06 +0800
                              Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-28 19:10 -0700
                                Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, Muttley@DastardlyHQ.org - 2025-06-29 07:46 +0000
                              Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, Muttley@DastardlyHQ.org - 2025-06-29 07:42 +0000
                                Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, wij <wyniijj5@gmail.com> - 2025-06-29 19:40 +0800
                                  Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, Muttley@dastardlyhq.com - 2025-06-29 16:05 +0000
                                    Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, wij <wyniijj5@gmail.com> - 2025-06-30 01:59 +0800
                                      Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, Muttley@DastardlyHQ.org - 2025-06-30 07:34 +0000
                                        Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, wij <wyniijj5@gmail.com> - 2025-06-30 21:56 +0800
                                          Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, Muttley@DastardlyHQ.org - 2025-06-30 15:42 +0000
                Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-06-26 16:00 +0000

Page 1 of 2  [1] 2  Next page →

#122345 — "Trip report: June 2025 ISO C++ standards meeting (Sofia, Bulgaria)" by Herb Sutter

"Trip report: June 2025 ISO C++ standards meeting (Sofia, Bulgaria)" by 
Herb Sutter
  
https://herbsutter.com/2025/06/21/trip-report-june-2025-iso-c-standards-meeting-sofia-bulgaria/

"Today marks a turning point in C++: A few minutes ago, the C++ 
committee voted the first seven (7) papers for compile-time reflection 
into draft C++26 to several sustained rounds of applause in the room. I 
think Hana “Ms. Constexpr” Dusíková summarized the impact of this 
feature best a few days ago, in her calm deadpan way… when she was told 
that the reflection paper was going to make it to the Saturday adoption 
poll, she gave a little shrug and just quietly said: “Whole new language.”"

Lynn

[toc] | [next] | [standalone]

#122349 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, Bulgaria)"

On Sun, 22 Jun 2025 19:37:39 -0500
Lynn McGuire <lynnmcguire5@gmail.com> gabbled:
>"Trip report: June 2025 ISO C++ standards meeting (Sofia, Bulgaria)" by 
>Herb Sutter
>  
>https://herbsutter.com/2025/06/21/trip-report-june-2025-iso-c-standards-meeting
>-sofia-bulgaria/
>
>"Today marks a turning point in C++: A few minutes ago, the C++ 
>committee voted the first seven (7) papers for compile-time reflection 

What for? What exactly does it bring to the table except more complexity in
an already overcomplex language?

>into draft C++26 to several sustained rounds of applause in the room. I 

From people who really have no life.

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

#122350 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia, Bulgaria)"

On Wed, 25 Jun 2025 08:47:23 -0000 (UTC)
Muttley@dastardlyhq.com wrote:

> On Sun, 22 Jun 2025 19:37:39 -0500
> Lynn McGuire <lynnmcguire5@gmail.com> gabbled:
> >"Trip report: June 2025 ISO C++ standards meeting (Sofia, Bulgaria)"
> >by Herb Sutter
> >  
> >https://herbsutter.com/2025/06/21/trip-report-june-2025-iso-c-standards-meeting
> >-sofia-bulgaria/
> >
> >"Today marks a turning point in C++: A few minutes ago, the C++ 
> >committee voted the first seven (7) papers for compile-time
> >reflection   
> 
> What for? What exactly does it bring to the table except more
> complexity in an already overcomplex language?
> 

Ability to serialize structures (for example, to JASON or XML) in generic way.

I didn't read the proposals, so not totally sure about it, but from
what Herb Sutter wrote it seems that ability to de-serialize into
arbitrary structures in generic way is not there yet, at least not
directly, but they are laying a foundation.

> >into draft C++26 to several sustained rounds of applause in the
> >room. I   
> 
> From people who really have no life.
>

Or may be, just may be, they found that proposals are really good?

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

#122351 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

On Wed, 25 Jun 2025 16:48:39 +0300
Michael S <already5chosen@yahoo.com> gabbled:
>On Wed, 25 Jun 2025 08:47:23 -0000 (UTC)
>Muttley@dastardlyhq.com wrote:
>
>> On Sun, 22 Jun 2025 19:37:39 -0500
>> Lynn McGuire <lynnmcguire5@gmail.com> gabbled:
>> >"Trip report: June 2025 ISO C++ standards meeting (Sofia, Bulgaria)"
>> >by Herb Sutter
>> >  
>>
>>https://herbsutter.com/2025/06/21/trip-report-june-2025-iso-c-standards-meetin
>g
>> >-sofia-bulgaria/
>> >
>> >"Today marks a turning point in C++: A few minutes ago, the C++ 
>> >committee voted the first seven (7) papers for compile-time
>> >reflection   
>> 
>> What for? What exactly does it bring to the table except more
>> complexity in an already overcomplex language?
>> 
>
>Ability to serialize structures (for example, to JASON or XML) in generic way.

I read something about that but it made no sense to me. Seemed to be a case
complex constexpr functions to do it with the fields and values hard coded
(obviously or no constexpr), but like most constexpressions IME, you can just
work out the result beforehand and hard code *that* instead.

Still, if the standards committee want to make the C++ learning curve for
beginners even steeper then they're going to succeed beyond their wildest
dreams. No wonder a lot of CS courses ditched C++ (and to be fair Java) a long
time a go and focused on Python.

>> From people who really have no life.
>>
>
>Or may be, just may be, they found that proposals are really good?

And? Its no difference to accountants going to a tax conference and giving
the latest deductable percentage reforms a standing ovation. It just says that
the people doing it really have a shrunken inner life.

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

#122352 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

Muttley@dastardlyhq.com writes:
>On Wed, 25 Jun 2025 16:48:39 +0300
>Michael S <already5chosen@yahoo.com> gabbled:
>>On Wed, 25 Jun 2025 08:47:23 -0000 (UTC)
>>Muttley@dastardlyhq.com wrote:
>>
>>> On Sun, 22 Jun 2025 19:37:39 -0500
>>> Lynn McGuire <lynnmcguire5@gmail.com> gabbled:
>>> >"Trip report: June 2025 ISO C++ standards meeting (Sofia, Bulgaria)"
>>> >by Herb Sutter
>>> >  
>>>
>>>https://herbsutter.com/2025/06/21/trip-report-june-2025-iso-c-standards-meetin
>>g
>>> >-sofia-bulgaria/
>>> >
>>> >"Today marks a turning point in C++: A few minutes ago, the C++ 
>>> >committee voted the first seven (7) papers for compile-time
>>> >reflection   
>>> 
>>> What for? What exactly does it bring to the table except more
>>> complexity in an already overcomplex language?
>>> 
>>
>>Ability to serialize structures (for example, to JASON or XML) in generic way.
>
>I read something about that but it made no sense to me. Seemed to be a case
>complex constexpr functions to do it with the fields and values hard coded
>(obviously or no constexpr), but like most constexpressions IME, you can just
>work out the result beforehand and hard code *that* instead.
>
>Still, if the standards committee want to make the C++ learning curve for
>beginners even steeper then they're going to succeed beyond their wildest
>dreams. No wonder a lot of CS courses ditched C++ (and to be fair Java) a long
>time a go and focused on Python.

Reflection was a useful feature in Java, I suspect that at least part
of the rationale for the addition to C++ is to match the corresponding
Java feature. 


https://www.oracle.com/technical-resources/articles/java/javareflection.html

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

#122353 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

On Wed, 25 Jun 2025 15:37:29 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:
>Muttley@dastardlyhq.com writes:
>>On Wed, 25 Jun 2025 16:48:39 +0300
>>Michael S <already5chosen@yahoo.com> gabbled:
>>>On Wed, 25 Jun 2025 08:47:23 -0000 (UTC)
>>>Muttley@dastardlyhq.com wrote:
>>>
>>>> On Sun, 22 Jun 2025 19:37:39 -0500
>>>> Lynn McGuire <lynnmcguire5@gmail.com> gabbled:
>>>> >"Trip report: June 2025 ISO C++ standards meeting (Sofia, Bulgaria)"
>>>> >by Herb Sutter
>>>> >  
>>>>
>>>>https://herbsutter.com/2025/06/21/trip-report-june-2025-iso-c-standards-meet
>in
>>>g
>>>> >-sofia-bulgaria/
>>>> >
>>>> >"Today marks a turning point in C++: A few minutes ago, the C++ 
>>>> >committee voted the first seven (7) papers for compile-time
>>>> >reflection   
>>>> 
>>>> What for? What exactly does it bring to the table except more
>>>> complexity in an already overcomplex language?
>>>> 
>>>
>>>Ability to serialize structures (for example, to JASON or XML) in generic
>way.
>>
>>I read something about that but it made no sense to me. Seemed to be a case
>>complex constexpr functions to do it with the fields and values hard coded
>>(obviously or no constexpr), but like most constexpressions IME, you can just
>>work out the result beforehand and hard code *that* instead.
>>
>>Still, if the standards committee want to make the C++ learning curve for
>>beginners even steeper then they're going to succeed beyond their wildest
>>dreams. No wonder a lot of CS courses ditched C++ (and to be fair Java) a long
>
>>time a go and focused on Python.
>
>Reflection was a useful feature in Java, I suspect that at least part
>of the rationale for the addition to C++ is to match the corresponding
>Java feature. 
>
>
>https://www.oracle.com/technical-resources/articles/java/javareflection.html

IIRC correctly the java version is runtime reflection, the C++ version will
be compile time which is utterly pointless. If the compiler knows whats there
at compile them then so do you and you can write your code accordingly.

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

#122354 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

On 25/06/2025 17:52, Muttley@dastardlyhq.com wrote:
> On Wed, 25 Jun 2025 15:37:29 GMT
> scott@slp53.sl.home (Scott Lurndal) gabbled:
>> Muttley@dastardlyhq.com writes:
>>> On Wed, 25 Jun 2025 16:48:39 +0300
>>> Michael S <already5chosen@yahoo.com> gabbled:
>>>> On Wed, 25 Jun 2025 08:47:23 -0000 (UTC)
>>>> Muttley@dastardlyhq.com wrote:
>>>>
>>>>> On Sun, 22 Jun 2025 19:37:39 -0500
>>>>> Lynn McGuire <lynnmcguire5@gmail.com> gabbled:
>>>>>> "Trip report: June 2025 ISO C++ standards meeting (Sofia, Bulgaria)"
>>>>>> by Herb Sutter
>>>>>>   
>>>>>
>>>>> https://herbsutter.com/2025/06/21/trip-report-june-2025-iso-c-standards-meet
>> in
>>>> g
>>>>>> -sofia-bulgaria/
>>>>>>
>>>>>> "Today marks a turning point in C++: A few minutes ago, the C++
>>>>>> committee voted the first seven (7) papers for compile-time
>>>>>> reflection
>>>>>
>>>>> What for? What exactly does it bring to the table except more
>>>>> complexity in an already overcomplex language?
>>>>>
>>>>
>>>> Ability to serialize structures (for example, to JASON or XML) in generic
>> way.
>>>
>>> I read something about that but it made no sense to me. Seemed to be a case
>>> complex constexpr functions to do it with the fields and values hard coded
>>> (obviously or no constexpr), but like most constexpressions IME, you can just
>>> work out the result beforehand and hard code *that* instead.
>>>
>>> Still, if the standards committee want to make the C++ learning curve for
>>> beginners even steeper then they're going to succeed beyond their wildest
>>> dreams. No wonder a lot of CS courses ditched C++ (and to be fair Java) a long
>>
>>> time a go and focused on Python.
>>
>> Reflection was a useful feature in Java, I suspect that at least part
>> of the rationale for the addition to C++ is to match the corresponding
>> Java feature.
>>
>>
>> https://www.oracle.com/technical-resources/articles/java/javareflection.html
> 
> IIRC correctly the java version is runtime reflection, the C++ version will
> be compile time which is utterly pointless. If the compiler knows whats there
> at compile them then so do you and you can write your code accordingly.
> 

I am not sure what your biggest problem is - your depressive pessimism, 
your ignorance, or your lack of imagination.  Have you ever actually 
written code in C++?  It is /full/ of features where the compiler knows 
something, and the programmer does not want to type it out manually 
every time - "auto", templates, constexpr functions, type traits, etc. 
Even C idioms like "p = malloc(100 * sizeof *p);" are asking the 
compiler to fill in something the programmer already knows.

You complain about C++ being complex - features like reflection make it 
/less/ complex in several ways.  It makes it far easier to make your own 
classes like tuples or variants (the std:: versions don't fit everyone). 
  There are all sorts of use-cases where reflection will let you write 
simpler C++ code, or write things only once but have the information 
available in different forms (enum->string and string->enum being the 
typical example).

And yes, you want /compile-time/ reflection in C++.  You can't do 
java-style runtime reflection without a common base class, which is an 
overhead C++ thankfully does not have.  But if you want run-time 
reflection in a class hierarchy, I am pretty sure it could be done using 
a virtual function in the base class, and CRTP inheritance in each 
descendant with compile-time reflection and templates in the 
implementation of the CRTP-inherited base.  That kind of thing will be 
fun to try out once C++26 is more complete.

I am certainly looking forward to reflection and contracts in C++26 - 
features that I had hoped to see long ago.

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

#122355 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

David Brown <david.brown@hesbynett.no> writes:
>On 25/06/2025 17:52, Muttley@dastardlyhq.com wrote:
>> On Wed, 25 Jun 2025 15:37:29 GMT
>> scott@slp53.sl.home (Scott Lurndal) gabbled:

>>> Reflection was a useful feature in Java, I suspect that at least part
>>> of the rationale for the addition to C++ is to match the corresponding
>>> Java feature.
>>>
>>>
>>> https://www.oracle.com/technical-resources/articles/java/javareflection.html
>> 
>> IIRC correctly the java version is runtime reflection, the C++ version will
>> be compile time which is utterly pointless. If the compiler knows whats there
>> at compile them then so do you and you can write your code accordingly.
>> 
>

>And yes, you want /compile-time/ reflection in C++.  You can't do 
>java-style runtime reflection without a common base class, which is an 
>overhead C++ thankfully does not have.

Indeed.    Although I wouldn't be surprised if Herb
introduced the common base class idea for C++YY
some year :-)

>  But if you want run-time 
>reflection in a class hierarchy, I am pretty sure it could be done using 
>a virtual function in the base class, and CRTP inheritance in each 
>descendant with compile-time reflection and templates in the 
>implementation of the CRTP-inherited base.  That kind of thing will be 
>fun to try out once C++26 is more complete.

One might even find that dynamic_cast<> provides a rather
limited form of run-time reflection.

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

#122356 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

On Wed, 25 Jun 2025 21:03:15 +0200
David Brown <david.brown@hesbynett.no> wibbled:
>On 25/06/2025 17:52, Muttley@dastardlyhq.com wrote:
>> IIRC correctly the java version is runtime reflection, the C++ version will
>> be compile time which is utterly pointless. If the compiler knows whats there
>
>> at compile them then so do you and you can write your code accordingly.
>> 
>
>I am not sure what your biggest problem is - your depressive pessimism, 
>your ignorance, or your lack of imagination.  Have you ever actually 

Can always rely on you to come out with an insult in the first few lines.
You must be a very insecure individual.

>written code in C++?  It is /full/ of features where the compiler knows 
>something, and the programmer does not want to type it out manually 
>every time - "auto", templates, constexpr functions, type traits, etc. 

Templates save a huge amount of cut and paste and often manual code mods.
constexpr's usualy return a single value that could easily be precomputed
either beforehand or just put in a macro. Meanwhile "if constexpr" seems to
just be a reinvention of the wheel in that the exact same can be achieved
with template specialisation. You won't be surprised to hear I've never yet
used a constexpr in any code I've written.

>Even C idioms like "p = malloc(100 * sizeof *p);" are asking the 
>compiler to fill in something the programmer already knows.

The size of p could vary on different architectures so no, thats not always 
the case.

>You complain about C++ being complex - features like reflection make it 
>/less/ complex in several ways.  It makes it far easier to make your own 

Oh please, we hear this cretinous refrain every time they chuck in yet more
semantics. I've yet to notice C++ becoming less complicated. The last genuinely
useful features was shared_mutex which frankly should have been in from the
start of adding threads. 3 level locking is a basic part of threading
functionality.

>  There are all sorts of use-cases where reflection will let you write 
>simpler C++ code, or write things only once but have the information 
>available in different forms (enum->string and string->enum being the 
>typical example).

Feel free to provide some before and after examples of code simplified 
using it.

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

#122357 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

On 26/06/2025 10:17, Muttley@DastardlyHQ.org wrote:
> On Wed, 25 Jun 2025 21:03:15 +0200
> David Brown <david.brown@hesbynett.no> wibbled:
>> On 25/06/2025 17:52, Muttley@dastardlyhq.com wrote:
>>> IIRC correctly the java version is runtime reflection, the C++ version will
>>> be compile time which is utterly pointless. If the compiler knows whats there
>>
>>> at compile them then so do you and you can write your code accordingly.
>>>
>>
>> I am not sure what your biggest problem is - your depressive pessimism,
>> your ignorance, or your lack of imagination.  Have you ever actually
> 
> Can always rely on you to come out with an insult in the first few lines.
> You must be a very insecure individual.

You made the first reply in this post with grumping, moaning and 
insulting everyone involved in the development of C++.

It's okay for you not to like particular new features, or not to like 
C++ at all.  Most C++ users only use a fraction of the language features.

However, the C++ standards committee, and the thousands of people who 
contribute to proposing new features, discussing proposals, implementing 
them in compilers and libraries, and otherwise working on the language 
do so because they think the features will make the language better for 
a non-negligible proportion of users.  They don't deserve your 
dismissive condemnation.

I wonder, did you even look at the linked blog post before you decided 
it was just for "people who really have no life" ?  It goes without 
saying that you didn't look at details of C++26 reflection before 
rejecting it.

> 
>> written code in C++?  It is /full/ of features where the compiler knows
>> something, and the programmer does not want to type it out manually
>> every time - "auto", templates, constexpr functions, type traits, etc.
> 
> Templates save a huge amount of cut and paste and often manual code mods.

Yes.

> constexpr's usualy return a single value that could easily be precomputed
> either beforehand or just put in a macro.

Constexpr data (and constexpr functions run at compile-time) return 
values that /are/ pre-computed.  That's the whole point.

How easily that is, and whether it is just one value, is another matter. 
  I have certainly used them with arrays in my own code, saving 
significant effort on my part.  Of course it could always have been 
pre-computed externally - such as a separate program that generated a 
C++ header or source file with the same information.

> Meanwhile "if constexpr" seems to
> just be a reinvention of the wheel in that the exact same can be achieved
> with template specialisation. 

I believe that anything that can be achieved with "if constexpr" could 
also be written using template specialisation, yes.  But in more 
complicated generic code, it is much simpler and clearer to use "if 
constexpr".  So it is "reinventing the wheel" in the same way that 
for-loops are reinventing the wheel in a language that has while-loops.

> You won't be surprised to hear I've never yet
> used a constexpr in any code I've written.
> 

I am not surprised, no.  I get the impression that you stopped learning 
or thinking about anything new a couple of decades ago.

In my work, it is always better to make the compiler work harder if it 
saves run-time effort, so I use it regularly.

>> Even C idioms like "p = malloc(100 * sizeof *p);" are asking the
>> compiler to fill in something the programmer already knows.
> 
> The size of p could vary on different architectures so no, thats not always
> the case.

Baring macro complications, you /always/ know the type of "p" because it 
is in code you wrote.  You always know the type of "*p", and you almost 
always know the size of "*p" - code portable across different sizes of 
the most common types is rare.  So why does the idiom use "sizeof *p" 
rather than, say, "sizeof(int)" when you have "int * p;" ?  People use 
it because it means that there is no risk of inconsistencies, either 
when writing the code or during later maintenance.  The same applies to 
using reflection - it means you don't need to re-write things yourself, 
and you won't make mistakes if there are later changes.

> 
>> You complain about C++ being complex - features like reflection make it
>> /less/ complex in several ways.  It makes it far easier to make your own
> 
> Oh please, we hear this cretinous refrain every time they chuck in yet more
> semantics. I've yet to notice C++ becoming less complicated. The last genuinely
> useful features was shared_mutex which frankly should have been in from the
> start of adding threads. 3 level locking is a basic part of threading
> functionality.
> 

The C++ /language/ becomes more complicated with each revision, because 
backwards compatibility means existing features are left even when 
better alternatives come along.  The point is to make the /code/ less 
complicated.

So when concepts were added, the language became more complex.  But code 
that previously used complicated "enable_if" clauses could be written in 
a clearer manner.  Adding "explicit" conversion operators made the 
language more complex - but it meant people could write safe boolean 
conversions without ridiculous complicated code.  Reflection complicates 
the language - I know without doubt that I can use it at times to 
simplify some of my code.

>>   There are all sorts of use-cases where reflection will let you write
>> simpler C++ code, or write things only once but have the information
>> available in different forms (enum->string and string->enum being the
>> typical example).
> 
> Feel free to provide some before and after examples of code simplified
> using it.
> 

You could start by looking at the proposal paper.

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

#122359 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

On Thu, 26 Jun 2025 15:41:39 +0200
David Brown <david.brown@hesbynett.no> wibbled:
>On 26/06/2025 10:17, Muttley@DastardlyHQ.org wrote:
>> Can always rely on you to come out with an insult in the first few lines.
>> You must be a very insecure individual.
>
>You made the first reply in this post with grumping, moaning and 
>insulting everyone involved in the development of C++.

Where did I "insult everyone"? And normal people know there's a big difference
between criticising an organisation and doing it to a specific individual.
Apart from you that is Mr Aspie.

>However, the C++ standards committee, and the thousands of people who 
>contribute to proposing new features, discussing proposals, implementing 
>them in compilers and libraries, and otherwise working on the language 
>do so because they think the features will make the language better for 
>a non-negligible proportion of users.  They don't deserve your 
>dismissive condemnation.

Wheres my violin when I need it...

>I wonder, did you even look at the linked blog post before you decided 
>it was just for "people who really have no life" ?  It goes without 
>saying that you didn't look at details of C++26 reflection before 
>rejecting it.

Its no different to the gormless idiots who applaud like demented seals at
corporate promo gigs when the CEO comes out holding the latest gizmo thats
slightly different to the last one but twice the price.

>> constexpr's usualy return a single value that could easily be precomputed
>> either beforehand or just put in a macro.
>
>Constexpr data (and constexpr functions run at compile-time) return 
>values that /are/ pre-computed.  That's the whole point.

The "whole point" is its a lot simpler code and less complicated if you
just hard code the damn value. Or would you suggest that instead of just
writing 3.14159... a constexpr should go work it out first?

>complicated generic code, it is much simpler and clearer to use "if 
>constexpr".  So it is "reinventing the wheel" in the same way that 

Not if you're already using templates anyway it isn't.

>for-loops are reinventing the wheel in a language that has while-loops.

Where are the init and loop sections in a while construct?

>I am not surprised, no.  I get the impression that you stopped learning 
>or thinking about anything new a couple of decades ago.

A wrong impression, but no surprise really.

>In my work, it is always better to make the compiler work harder if it 
>saves run-time effort, so I use it regularly.

At the expense of a more complicated codebase which no doubt maintenance 
coders down the line will thank you for. They'll realise how important the
5 mins of your life you saved working out value manually and just plugging it
in was for you.

>> The size of p could vary on different architectures so no, thats not always
>> the case.
>
>Baring macro complications, you /always/ know the type of "p" because it 
>is in code you wrote.  You always know the type of "*p", and you almost 

So what size is "int" then?

>The C++ /language/ becomes more complicated with each revision, because 
>backwards compatibility means existing features are left even when 
>better alternatives come along.  The point is to make the /code/ less 
>complicated.

If only one day they might succeed. We can hope.

>> Feel free to provide some before and after examples of code simplified
>> using it.
>> 
>
>You could start by looking at the proposal paper.

I've looked at a number of tentative examples of the new feature. The code 
looked an utter mess.

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

#122360 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

On Thu, 2025-06-26 at 15:41 +0200, David Brown wrote:
> On 26/06/2025 10:17, Muttley@DastardlyHQ.org wrote:
> > On Wed, 25 Jun 2025 21:03:15 +0200
> > David Brown <david.brown@hesbynett.no> wibbled:
> > > On 25/06/2025 17:52, Muttley@dastardlyhq.com wrote:
> > > > IIRC correctly the java version is runtime reflection, the C++ version will
> > > > be compile time which is utterly pointless. If the compiler knows whats there
> > > 
> > > > at compile them then so do you and you can write your code accordingly.
> > > > 
> > > 
> > > I am not sure what your biggest problem is - your depressive pessimism,
> > > your ignorance, or your lack of imagination.  Have you ever actually
> > 
> > Can always rely on you to come out with an insult in the first few lines.
> > You must be a very insecure individual.
> 
> You made the first reply in this post with grumping, moaning and 
> insulting everyone involved in the development of C++.
> 
> It's okay for you not to like particular new features, or not to like 
> C++ at all.  Most C++ users only use a fraction of the language features.
> 
> However, the C++ standards committee, and the thousands of people who 
> contribute to proposing new features, discussing proposals, implementing 
> them in compilers and libraries, and otherwise working on the language 
> do so because they think the features will make the language better for 
> a non-negligible proportion of users.  They don't deserve your 
> dismissive condemnation.
> 
> I wonder, did you even look at the linked blog post before you decided 
> it was just for "people who really have no life" ?  It goes without 
> saying that you didn't look at details of C++26 reflection before 
> rejecting it.

The above is read like tolling.

> > 
> > > written code in C++?  It is /full/ of features where the compiler knows
> > > something, and the programmer does not want to type it out manually
> > > every time - "auto", templates, constexpr functions, type traits, etc.
> > 
> > Templates save a huge amount of cut and paste and often manual code mods.
> 
> Yes.
> 
> > constexpr's usualy return a single value that could easily be precomputed
> > either beforehand or just put in a macro.
> 
> Constexpr data (and constexpr functions run at compile-time) return 
> values that /are/ pre-computed.  That's the whole point.
> 
> How easily that is, and whether it is just one value, is another matter. 
>   I have certainly used them with arrays in my own code, saving 
> significant effort on my part.  Of course it could always have been 
> pre-computed externally - such as a separate program that generated a 
> C++ header or source file with the same information.
> 
> > Meanwhile "if constexpr" seems to
> > just be a reinvention of the wheel in that the exact same can be achieved
> > with template specialisation. 
> 
> I believe that anything that can be achieved with "if constexpr" could 
> also be written using template specialisation, yes.  But in more 
> complicated generic code, it is much simpler and clearer to use "if 
> constexpr".  So it is "reinventing the wheel" in the same way that 
> for-loops are reinventing the wheel in a language that has while-loops.
> 
> > You won't be surprised to hear I've never yet
> > used a constexpr in any code I've written.
> > 
> 
> I am not surprised, no.  I get the impression that you stopped learning 
> or thinking about anything new a couple of decades ago.
> 
> In my work, it is always better to make the compiler work harder if it 
> saves run-time effort, so I use it regularly.
> 
> > > Even C idioms like "p = malloc(100 * sizeof *p);" are asking the
> > > compiler to fill in something the programmer already knows.
> > 
> > The size of p could vary on different architectures so no, thats not always
> > the case.
> 
> Baring macro complications, you /always/ know the type of "p" because it 
> is in code you wrote.  You always know the type of "*p", and you almost 
> always know the size of "*p" - code portable across different sizes of 
> the most common types is rare.  So why does the idiom use "sizeof *p" 
> rather than, say, "sizeof(int)" when you have "int * p;" ?  People use 
> it because it means that there is no risk of inconsistencies, either 
> when writing the code or during later maintenance.  The same applies to 
> using reflection - it means you don't need to re-write things yourself, 
> and you won't make mistakes if there are later changes.
> 
> > 
> > > You complain about C++ being complex - features like reflection make it
> > > /less/ complex in several ways.  It makes it far easier to make your own
> > 
> > Oh please, we hear this cretinous refrain every time they chuck in yet more
> > semantics. I've yet to notice C++ becoming less complicated. The last genuinely
> > useful features was shared_mutex which frankly should have been in from the
> > start of adding threads. 3 level locking is a basic part of threading
> > functionality.
> > 
> 
> The C++ /language/ becomes more complicated with each revision, because 
> backwards compatibility means existing features are left even when 
> better alternatives come along.  The point is to make the /code/ less 
> complicated.
> 
> So when concepts were added, the language became more complex.  But code 
> that previously used complicated "enable_if" clauses could be written in 
> a clearer manner.  Adding "explicit" conversion operators made the 
> language more complex - but it meant people could write safe boolean 
> conversions without ridiculous complicated code.  Reflection complicates 
> the language - I know without doubt that I can use it at times to 
> simplify some of my code.
> 
> > >   There are all sorts of use-cases where reflection will let you write
> > > simpler C++ code, or write things only once but have the information
> > > available in different forms (enum->string and string->enum being the
> > > typical example).
> > 
> > Feel free to provide some before and after examples of code simplified
> > using it.
> > 
> 
> You could start by looking at the proposal paper.

The problem of 'new' C++ is that rare real innovation but lots about specific
kinds of functions that are already covered by various kinds of libraries....
C++ seems mostly interested in making existing technique convenient and 'only'
dealing with 'small' (or part of) problems (e.g. avoiding to deal with graphics 
or provide basic facilities).
But, nothing in all is actually wrong with the above, if C++ is 'in developing'.

Duplicates are no good to portability, reusability....

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

#122363 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

On 27/06/2025 06:56, wij wrote:

> The problem of 'new' C++ is that rare real innovation but lots about specific
> kinds of functions that are already covered by various kinds of libraries....
> C++ seems mostly interested in making existing technique convenient and 'only'
> dealing with 'small' (or part of) problems (e.g. avoiding to deal with graphics
> or provide basic facilities).
> But, nothing in all is actually wrong with the above, if C++ is 'in developing'.
> 

I think it is a good thing that the language is making existing 
techniques and code more convenient - that's better for the developer 
writing source code and/or more efficient for the run-time code.

But C++ has also evolved to allow very different kinds of techniques. 
 From C++11 onwards, it has changed from being "safer C with classes" 
into a language with increasing support for functional programming 
styles (lambdas, ranges), more generic programming (auto, more 
templates), compile-time programming (constexpr, consteval), 
requirements specifications (concepts, static assertions), 
multi-threading (threads, locks), asynchronous programming (coroutines), 
etc.

C++26 continues that trend - improving a number of existing techniques, 
and adding significant new ones (reflection and contracts).

You are right that it does not tackle the "big" things like graphics 
libraries.  Attempts to add networking have stalled AFAIUI.  In 
comparison to, say, Python, the standard library is much smaller.

I think this is, for the most part, fine.  I don't believe C++ should 
have these things in its standard library.  Python can have these, 
because Python is already huge and works on only a small number of 
platforms - basically, *nix and Win32/Win64.  C++ needs to be useable on 
a very much wider range of platforms now and in the future.  How can you 
have a truly portable networking standard library in C++ when there are 
dozens of networking stacks in use?  How can you have a standard 
graphics library for C++ when there are hundreds of graphics libraries 
used by C++ programmers, some of which are orders of magnitude bigger 
development projects than current standard C++?

 From the users' viewpoint, having more "big" features in a standard 
library for a language can often be a good thing.  I think there could 
be a lot of benefits from a repository project for quality 
cross-platform libraries for C++.  Boost is the nearest we have, but it 
is under-funded, inconsistent, poorly maintained, has jumbled 
dependencies, and poor quality control.  A real solution here would take 
considerable financial backing, because it would be a huge amount of work.



> Duplicates are no good to portability, reusability....
> 

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

#122372 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

On Fri, 2025-06-27 at 10:53 +0200, David Brown wrote:
> On 27/06/2025 06:56, wij wrote:
> 
> > The problem of 'new' C++ is that rare real innovation but lots about specific
> > kinds of functions that are already covered by various kinds of libraries....
> > C++ seems mostly interested in making existing technique convenient and 'only'
> > dealing with 'small' (or part of) problems (e.g. avoiding to deal with graphics
> > or provide basic facilities).
> > But, nothing in all is actually wrong with the above, if C++ is 'in developing'.
> > 
> 
> I think it is a good thing that the language is making existing 
> techniques and code more convenient - that's better for the developer 
> writing source code and/or more efficient for the run-time code.
> 
> But C++ has also evolved to allow very different kinds of techniques. 
>  From C++11 onwards, it has changed from being "safer C with classes" 
> into a language with increasing support for functional programming 
> styles (lambdas, ranges), more generic programming (auto, more 
> templates), compile-time programming (constexpr, consteval), 
> requirements specifications (concepts, static assertions), 
> multi-threading (threads, locks), asynchronous programming (coroutines), 
> etc.
> 
> C++26 continues that trend - improving a number of existing techniques, 
> and adding significant new ones (reflection and contracts).

What about if I say those many (not all) are 'programming style', ie. C++ 
invents 'standard' programming style while its propaganda says C++ is a   
"multi-lingual" language?

> You are right that it does not tackle the "big" things like graphics 
> libraries.  Attempts to add networking have stalled AFAIUI.  In 
> comparison to, say, Python, the standard library is much smaller.
> 
> I think this is, for the most part, fine.  I don't believe C++ should 
> have these things in its standard library.  Python can have these, 
> because Python is already huge and works on only a small number of 
> platforms - basically, *nix and Win32/Win64.  C++ needs to be useable on 
> a very much wider range of platforms now and in the future.  How can you 
> have a truly portable networking standard library in C++ when there are 
> dozens of networking stacks in use?  How can you have a standard 
> graphics library for C++ when there are hundreds of graphics libraries 
> used by C++ programmers, some of which are orders of magnitude bigger 
> development projects than current standard C++?
> 
>  From the users' viewpoint, having more "big" features in a standard 
> library for a language can often be a good thing.  I think there could 
> be a lot of benefits from a repository project for quality 
> cross-platform libraries for C++.  Boost is the nearest we have, but it 
> is under-funded, inconsistent, poorly maintained, has jumbled 
> dependencies, and poor quality control.  A real solution here would take 
> considerable financial backing, because it would be a huge amount of work.

There could be 'standard way' of programming for some well defined applications
(but, why not inventing it earlier?).
C++ seems developing toward supporting specific applications directly, and 
steering away from system programming (it is not easy for C++ to write 
system programs like 'cp', merely copying files correctly and safer on a
platform). I just don't know what the C++ std-lib aims for.

> 
> > Duplicates are no good to portability, reusability....
> > 
> 

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

#122376 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

On 28/06/2025 09:16, wij wrote:
> On Fri, 2025-06-27 at 10:53 +0200, David Brown wrote:
>> On 27/06/2025 06:56, wij wrote:
>>
>>> The problem of 'new' C++ is that rare real innovation but lots about specific
>>> kinds of functions that are already covered by various kinds of libraries....
>>> C++ seems mostly interested in making existing technique convenient and 'only'
>>> dealing with 'small' (or part of) problems (e.g. avoiding to deal with graphics
>>> or provide basic facilities).
>>> But, nothing in all is actually wrong with the above, if C++ is 'in developing'.
>>>
>>
>> I think it is a good thing that the language is making existing
>> techniques and code more convenient - that's better for the developer
>> writing source code and/or more efficient for the run-time code.
>>
>> But C++ has also evolved to allow very different kinds of techniques.
>>   From C++11 onwards, it has changed from being "safer C with classes"
>> into a language with increasing support for functional programming
>> styles (lambdas, ranges), more generic programming (auto, more
>> templates), compile-time programming (constexpr, consteval),
>> requirements specifications (concepts, static assertions),
>> multi-threading (threads, locks), asynchronous programming (coroutines),
>> etc.
>>
>> C++26 continues that trend - improving a number of existing techniques,
>> and adding significant new ones (reflection and contracts).
> 
> What about if I say those many (not all) are 'programming style', ie. C++
> invents 'standard' programming style while its propaganda says C++ is a
> "multi-lingual" language?

I'm sorry, I don't understand what you are trying to say here.  I think 
the term commonly used is "programming paradigm" - where "imperative", 
"generic", "functional", "object oriented", etc., are "paradigms".  And 
sometimes within a single language, these are referred to as 
"programming styles".  Often the use of these terms, and the 
distinctions between them, are somewhat artificial.

My point is just that C++ has evolved to let you write code in 
significantly different ways.  If those other ways work better for the 
problem you are trying to solve, then that's a good thing.  If they 
don't, then feel free to ignore them in your code.

> 
>> You are right that it does not tackle the "big" things like graphics
>> libraries.  Attempts to add networking have stalled AFAIUI.  In
>> comparison to, say, Python, the standard library is much smaller.
>>
>> I think this is, for the most part, fine.  I don't believe C++ should
>> have these things in its standard library.  Python can have these,
>> because Python is already huge and works on only a small number of
>> platforms - basically, *nix and Win32/Win64.  C++ needs to be useable on
>> a very much wider range of platforms now and in the future.  How can you
>> have a truly portable networking standard library in C++ when there are
>> dozens of networking stacks in use?  How can you have a standard
>> graphics library for C++ when there are hundreds of graphics libraries
>> used by C++ programmers, some of which are orders of magnitude bigger
>> development projects than current standard C++?
>>
>>   From the users' viewpoint, having more "big" features in a standard
>> library for a language can often be a good thing.  I think there could
>> be a lot of benefits from a repository project for quality
>> cross-platform libraries for C++.  Boost is the nearest we have, but it
>> is under-funded, inconsistent, poorly maintained, has jumbled
>> dependencies, and poor quality control.  A real solution here would take
>> considerable financial backing, because it would be a huge amount of work.
> 
> There could be 'standard way' of programming for some well defined applications
> (but, why not inventing it earlier?).
> C++ seems developing toward supporting specific applications directly, and
> steering away from system programming (it is not easy for C++ to write
> system programs like 'cp', merely copying files correctly and safer on a
> platform). I just don't know what the C++ std-lib aims for.
> 

I disagree.  C++ can be, and is, used for a wide variety of different 
kinds of programming.  Not all aspects of the language and standard 
library and suitable for all kinds of programming, naturally.

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

#122390 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

On Sat, 2025-06-28 at 17:09 +0200, David Brown wrote:
> On 28/06/2025 09:16, wij wrote:
> > On Fri, 2025-06-27 at 10:53 +0200, David Brown wrote:
> > > On 27/06/2025 06:56, wij wrote:
> > > 
> > > > The problem of 'new' C++ is that rare real innovation but lots about specific
> > > > kinds of functions that are already covered by various kinds of libraries....
> > > > C++ seems mostly interested in making existing technique convenient and 'only'
> > > > dealing with 'small' (or part of) problems (e.g. avoiding to deal with graphics
> > > > or provide basic facilities).
> > > > But, nothing in all is actually wrong with the above, if C++ is 'in developing'.
> > > > 
> > > 
> > > I think it is a good thing that the language is making existing
> > > techniques and code more convenient - that's better for the developer
> > > writing source code and/or more efficient for the run-time code.
> > > 
> > > But C++ has also evolved to allow very different kinds of techniques.
> > >   From C++11 onwards, it has changed from being "safer C with classes"
> > > into a language with increasing support for functional programming
> > > styles (lambdas, ranges), more generic programming (auto, more
> > > templates), compile-time programming (constexpr, consteval),
> > > requirements specifications (concepts, static assertions),
> > > multi-threading (threads, locks), asynchronous programming (coroutines),
> > > etc.
> > > 
> > > C++26 continues that trend - improving a number of existing techniques,
> > > and adding significant new ones (reflection and contracts).
> > 
> > What about if I say those many (not all) are 'programming style', ie. C++
> > invents 'standard' programming style while its propaganda says C++ is a
> > "multi-lingual" language?
> 
> I'm sorry, I don't understand what you are trying to say here.  I think 
> the term commonly used is "programming paradigm" - where "imperative", 
> "generic", "functional", "object oriented", etc., are "paradigms".  And 
> sometimes within a single language, these are referred to as 
> "programming styles".  Often the use of these terms, and the 
> distinctions between them, are somewhat artificial.
> 
> My point is just that C++ has evolved to let you write code in 
> significantly different ways.  If those other ways work better for the 
> problem you are trying to solve, then that's a good thing.  If they 
> don't, then feel free to ignore them in your code.
> 

But I think "one language suits all" (multi-paradigm) is a problematic ideal.
It is like the idea of 'universal compiler'.

I would measure 'multi-paradigm' this way:
Easier to program: Yes or no (increasing complexity)
Easier to understand: ditto (probably yes for documentation)
Less error prone: ditto
Less codes: yes (the lean side is more 'abstract')
maintenance: ???
debug: should be harder
...
Conclusion: What all the efforts are for? Seems only good for experenced user.

But yes, you are right, I only use those parts that suit 'my standard'.
The conseqences are other people's codes are less useful for me (vise versa).
Then this is a point: Program communication, 23n share,..

> > > You are right that it does not tackle the "big" things like graphics
> > > libraries.  Attempts to add networking have stalled AFAIUI.  In
> > > comparison to, say, Python, the standard library is much smaller.
> > > 
> > > I think this is, for the most part, fine.  I don't believe C++ should
> > > have these things in its standard library.  Python can have these,
> > > because Python is already huge and works on only a small number of
> > > platforms - basically, *nix and Win32/Win64.  C++ needs to be useable on
> > > a very much wider range of platforms now and in the future.  How can you
> > > have a truly portable networking standard library in C++ when there are
> > > dozens of networking stacks in use?  How can you have a standard
> > > graphics library for C++ when there are hundreds of graphics libraries
> > > used by C++ programmers, some of which are orders of magnitude bigger
> > > development projects than current standard C++?
> > > 
> > >   From the users' viewpoint, having more "big" features in a standard
> > > library for a language can often be a good thing.  I think there could
> > > be a lot of benefits from a repository project for quality
> > > cross-platform libraries for C++.  Boost is the nearest we have, but it
> > > is under-funded, inconsistent, poorly maintained, has jumbled
> > > dependencies, and poor quality control.  A real solution here would take
> > > considerable financial backing, because it would be a huge amount of work.
> > 
> > There could be 'standard way' of programming for some well defined applications
> > (but, why not inventing it earlier?).
> > C++ seems developing toward supporting specific applications directly, and
> > steering away from system programming (it is not easy for C++ to write
> > system programs like 'cp', merely copying files correctly and safer on a
> > platform). I just don't know what the C++ std-lib aims for.
> > 
> 
> I disagree.  C++ can be, and is, used for a wide variety of different 
> kinds of programming.  Not all aspects of the language and standard 
> library and suitable for all kinds of programming, naturally.
> 
> 

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

#122397 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

On 28/06/2025 19:24, wij wrote:
> On Sat, 2025-06-28 at 17:09 +0200, David Brown wrote:
>> On 28/06/2025 09:16, wij wrote:
>>> On Fri, 2025-06-27 at 10:53 +0200, David Brown wrote:
>>>> On 27/06/2025 06:56, wij wrote:
>>>>
>>>>> The problem of 'new' C++ is that rare real innovation but lots about specific
>>>>> kinds of functions that are already covered by various kinds of libraries....
>>>>> C++ seems mostly interested in making existing technique convenient and 'only'
>>>>> dealing with 'small' (or part of) problems (e.g. avoiding to deal with graphics
>>>>> or provide basic facilities).
>>>>> But, nothing in all is actually wrong with the above, if C++ is 'in developing'.
>>>>>
>>>>
>>>> I think it is a good thing that the language is making existing
>>>> techniques and code more convenient - that's better for the developer
>>>> writing source code and/or more efficient for the run-time code.
>>>>
>>>> But C++ has also evolved to allow very different kinds of techniques.
>>>>    From C++11 onwards, it has changed from being "safer C with classes"
>>>> into a language with increasing support for functional programming
>>>> styles (lambdas, ranges), more generic programming (auto, more
>>>> templates), compile-time programming (constexpr, consteval),
>>>> requirements specifications (concepts, static assertions),
>>>> multi-threading (threads, locks), asynchronous programming (coroutines),
>>>> etc.
>>>>
>>>> C++26 continues that trend - improving a number of existing techniques,
>>>> and adding significant new ones (reflection and contracts).
>>>
>>> What about if I say those many (not all) are 'programming style', ie. C++
>>> invents 'standard' programming style while its propaganda says C++ is a
>>> "multi-lingual" language?
>>
>> I'm sorry, I don't understand what you are trying to say here.  I think
>> the term commonly used is "programming paradigm" - where "imperative",
>> "generic", "functional", "object oriented", etc., are "paradigms".  And
>> sometimes within a single language, these are referred to as
>> "programming styles".  Often the use of these terms, and the
>> distinctions between them, are somewhat artificial.
>>
>> My point is just that C++ has evolved to let you write code in
>> significantly different ways.  If those other ways work better for the
>> problem you are trying to solve, then that's a good thing.  If they
>> don't, then feel free to ignore them in your code.
>>
> 
> But I think "one language suits all" (multi-paradigm) is a problematic ideal.
> It is like the idea of 'universal compiler'.
> 

"One language suits all" and "multi-paradigm" are /completely/ different 
concepts.  Saying C++ is "one language that suits all" is like saying 
everyone should drive a Toyota Corolla - that one car will suit 
everyone.  Saying C++ is "multi-paradigm" is like saying a Toyota RAV4 
is good for town driving, long distance car vacations, and pulling a 
horse box.

No one, AFAIK, has ever suggested that C++ is suitable for all tasks, 
much less a language that suits all people.  It covers a wider range of 
tasks than most languages, but very far from all.

But there is no doubt that it is a multi-paradigm language.  And there 
is no doubt that some people choose to write C++ code that is imperative 
(like C with stronger types and namespaces), most use object oriented 
programming to some extent (though many have very simple hierarchies), 
many will do a bit of generic programming.  Some people like functional 
style with lambdas and ranges, but many do not.

There are limitations to supporting all this.  The syntax for some 
features can be awkward, and the implementations can be less efficient 
or less flexible than a more dedicated language of that paradigm.  If 
you want to do serious function programming, you are better off with a 
functional programming language - but if you think that part of your C++ 
code could be better expressed in a functional style, then use that. 
(People do the same with Python.)

> I would measure 'multi-paradigm' this way:
> Easier to program: Yes or no (increasing complexity)
> Easier to understand: ditto (probably yes for documentation)
> Less error prone: ditto
> Less codes: yes (the lean side is more 'abstract')
> maintenance: ???
> debug: should be harder
> ...

Most design decisions in most languages are tradeoffs, with their pros 
and cons.  You only need to look at the size of the C++ standard to see 
the major downside - it is a big, complex language, and there are many 
gotchas.  If you don't think it is worth it, use a different language 
(and that includes earlier C++ standards as an option - most toolchains 
continue to support older versions of C++).

> Conclusion: What all the efforts are for? Seems only good for experenced user.

Certainly some parts of C++ are primarily used in code by very 
experienced users.  But that's okay.  Let the more dedicated "C++ 
wizards" write the code for implementing std::vector<> and the rest. 
Let /them/ worry about how move semantics work, and when different type 
traits are needed.  The rest of us can reap the benefits when we /use/ 
these classes, without having to understand the details.

> 
> But yes, you are right, I only use those parts that suit 'my standard'.
> The conseqences are other people's codes are less useful for me (vise versa).
> Then this is a point: Program communication, 23n share,..
> 

When people write modular code, it's okay that different people use 
different language features to get the best implementation of their 
part.  With a big program, you don't expect to understand all of it. 
This is normal for programming - even if you stick to a relatively small 
language like C.

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

#122364 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

On Fri, 27 Jun 2025 12:56:17 +0800
wij <wyniijj5@gmail.com> wibbled:
>On Thu, 2025-06-26 at 15:41 +0200, David Brown wrote:
>dealing with 'small' (or part of) problems (e.g. avoiding to deal with grap=
>hics=20
>or provide basic facilities).

A multi platform language has no business having something like graphics built
in. There are too many variations on different systems and some don't have
graphics at all. Also unless you release a new version of C++ everytime eg
NVidia updates the Cuda functionality then you'll have to use libraries anyway.

IMO C++ should never have included threads because the original model was
a half arsed implementation probably skewed towards Windows rather than unix
and now there's the inconsistency of C++ natively supporting multithreading
but not multiprocess.

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

#122365 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

On 6/27/2025 5:21 AM, Muttley@DastardlyHQ.org wrote:
> On Fri, 27 Jun 2025 12:56:17 +0800
> wij <wyniijj5@gmail.com> wibbled:
>> On Thu, 2025-06-26 at 15:41 +0200, David Brown wrote:
>> dealing with 'small' (or part of) problems (e.g. avoiding to deal with grap=
>> hics=20
>> or provide basic facilities).
> 
> A multi platform language has no business having something like graphics built
> in. 

Agreed. However, it would be interesting if it had support for creating 
PPM's. lol. That's fairly low level. Well, it matters not. ;^)


> There are too many variations on different systems and some don't have
> graphics at all. Also unless you release a new version of C++ everytime eg
> NVidia updates the Cuda functionality then you'll have to use libraries anyway.
> 
> IMO C++ should never have included threads because the original model was
> a half arsed implementation probably skewed towards Windows rather than unix
> and now there's the inconsistency of C++ natively supporting multithreading
> but not multiprocess.
> 

Humm... Having std threads is a good idea along with membars. But, 
that's my personal thoughts. Before we had to use POSIX and a 
"sufficient" compiler. Now that its in the language, its much better... 
I don't have to create custom ASM libs for everything that is low level. 
An example:

https://web.archive.org/web/20060214112345/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_gcc_asm.html

Can't believe its still there way back from 2005. Wow, how time flies. :^)

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

#122371 — Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

On Fri, 2025-06-27 at 12:21 +0000, Muttley@DastardlyHQ.org wrote:
> On Fri, 27 Jun 2025 12:56:17 +0800
> wij <wyniijj5@gmail.com> wibbled:
> > On Thu, 2025-06-26 at 15:41 +0200, David Brown wrote:
> > dealing with 'small' (or part of) problems (e.g. avoiding to deal with grap=
> > hics=20
> > or provide basic facilities).
> 
> A multi platform language has no business having something like graphics built
> in. There are too many variations on different systems and some don't have
> graphics at all. Also unless you release a new version of C++ everytime eg
> NVidia updates the Cuda functionality then you'll have to use libraries anyway.

There are various level of 'graphics'.
The point is a 'C++ graphics' so that a C++ program can draw Shape (as C++ demo
its OO capability). It would be just like cout, you don't need to worry about
what the low level stuff is.

> IMO C++ should never have included threads because the original model was
> a half arsed implementation probably skewed towards Windows rather than unix
> and now there's the inconsistency of C++ natively supporting multithreading
> but not multiprocess.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web