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.