"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
On Sun, 22 Jun 2025 19:37:39 -0500
Lynn McGuire <[email protected]> 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.
On Wed, 25 Jun 2025 08:47:23 -0000 (UTC)
[email protected] wrote:
On Sun, 22 Jun 2025 19:37:39 -0500g
Lynn McGuire <[email protected]> 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
-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.
From people who really have no life.
Or may be, just may be, they found that proposals are really good?
[email protected] writes:
On Wed, 25 Jun 2025 16:48:39 +0300in
Michael S <[email protected]> gabbled:
On Wed, 25 Jun 2025 08:47:23 -0000 (UTC)
[email protected] wrote:
On Sun, 22 Jun 2025 19:37:39 -0500
Lynn McGuire <[email protected]> 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
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
On Wed, 25 Jun 2025 16:48:39 +0300
Michael S <[email protected]> gabbled:
On Wed, 25 Jun 2025 08:47:23 -0000 (UTC)
[email protected] wrote:
On Sun, 22 Jun 2025 19:37:39 -0500g
Lynn McGuire <[email protected]> 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
-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.
On Wed, 25 Jun 2025 15:37:29 GMT
[email protected] (Scott Lurndal) gabbled:
[email protected] writes:
On Wed, 25 Jun 2025 16:48:39 +0300in
Michael S <[email protected]> gabbled:
On Wed, 25 Jun 2025 08:47:23 -0000 (UTC)
[email protected] wrote:
On Sun, 22 Jun 2025 19:37:39 -0500
Lynn McGuire <[email protected]> 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
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.
On 25/06/2025 17:52, [email protected] wrote:
On Wed, 25 Jun 2025 15:37:29 GMT
[email protected] (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.
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.
On 25/06/2025 17:52, [email protected] 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
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
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).
On Wed, 25 Jun 2025 21:03:15 +0200
David Brown <[email protected]> wibbled:
On 25/06/2025 17:52, [email protected] 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.
On 26/06/2025 10:17, [email protected] 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++.
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.
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.
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.
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.
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
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.
Feel free to provide some before and after examples of code simplified
using it.
You could start by looking at the proposal paper.
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).
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....
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).
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.
On Fri, 2025-06-27 at 12:21 +0000, [email protected] wrote:
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 hav= >e
graphics at all. Also unless you release a new version of C++ everytime e= >g
NVidia updates the Cuda functionality then you'll have to use libraries a= >nyway.
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 abo= >ut
what the low level stuff is.
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,..
On 6/28/2025 10:06 AM, wij wrote:
Nope, because "..There are too many variations on different systems and some >don't have..."?
Made me think of printf("Hello"), can show rendered glyph's on a
console? Them be Graphics.... lol. ;^)
On Sat, 2025-06-28 at 15:37 +0000, [email protected] wrote:
properties will it have?=20=20
I'm guessing you've never done graphics programming. You might as well=
suggest C++ has built in sound.
Why not, if a C++ book demonstrated an example:
int main() {
utter << "Hellow, world";
};
Nope, because "..There are too many variations on different systems and som= >e don't have..."?
On Sun, 2025-06-29 at 07:42 +0000, [email protected] wrote:
Oh, so not just sound but speech synthesis! Obviously trivial to implemen= >t,
why don't you go and do it?
I had designed and built a sound car. I have all the ability to implement w= >hat
I want. But all are not trivial to me.
Linux doesn't have a standard built in speech synthesiser. What would you=20
suggest speaks the words? Or is that a load of having wavey stuff that is
Someone Elses Problem, you just want the praise for coming up with the=
incredibly original idea, right?
Speech synthesizer already existed 35 years ago on PC-XT+DOS which only=C2= >=A0
equipped with a buzzer (can only produce '1/0' sound).
There are many know-how there. Yes, your doubt is confirmed that you are id= >iot.
A clue for you. The two-state buzzer can be programmed to simulate analog s= >ound
(bad quality) You know C/C++ does not mean you can really do programming.
On Sun, 2025-06-29 at 16:05 +0000, [email protected] wrote:
something you're apparently completely unaware of. The same applies to==20
graphics. Now why don't you go find a time machine, come forward 40 years=to
2025 then get yourself a clue.
I can write a speech synthesizer 'utter', like bellow, to say "Hellow, worl= >d".
(Honest, this one would take time for now)
int main() {
utter << "Hellow, world";
};
I can write a program like below that paint an image and draw a cross.
Most importantly, no graphics library is compiled and needed in the source= >=C2=A0
(all source is pretty much what the several lines shown).
int main() {
Image imgfile(..);
Display disp(..);
disp << imgfile;
disp << "line(100,200,200,300),line(100,300,200,100),..";
What you can do? just mouth -> Oh, not in OS1, OS2,...OS100. Or C/C++,Pytho= >n,C#,
Java,Go,Dust,... have no such thing, non-standard ABC,... Or that need OS/ >hardware/BIOS... support,..too complicated... (pretending very knowledgeabl=
e).=20
Finally, 'we' don't need graphics/sound library in C++ !!!
On Mon, 2025-06-30 at 07:34 +0000, [email protected] wrote:
So "I could write a library to do speech synthesis" becomes "it should be
built into the language". Right, ok. How would the setup work then, give = >some
examples?
It looks? I saved too many typing of keyboard.
I read the post twice to figure out your post is loser's trolling.
Those who know C++ programming should already get the idea.
I am not wasting my time with idiot. Go home and learn more.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 11:26:10 |
| Calls: | 12,100 |
| Files: | 15,003 |
| Messages: | 6,517,994 |