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....