Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: wij <wyniijj5@gmail.com>
Newsgroups: comp.lang.c++
Subject: Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,
Date: Fri, 27 Jun 2025 12:56:17 +0800
Organization: A noiseless patient Spider
Lines: 188
Message-ID: <c6c7eeec9a6993ca2d49bfadd02fb2162531c939.camel@gmail.com>
References: <103a7kk$qri0$2@dont-email.me> <103gd2r$2lqoe$1@dont-email.me>
	 <20250625164839.000004b5@yahoo.com> <103h2sf$2rb11$1@dont-email.me>
	 <ZIU6Q.130533$wybc.75864@fx17.iad> <103h604$2s3vq$1@dont-email.me>
	 <103hh5j$2ui1d$1@dont-email.me> <103ivnj$3btbj$1@dont-email.me>
	 <103jimj$3g1be$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Injection-Date: Fri, 27 Jun 2025 06:56:19 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e916c8f5a6510b30354aa1c227626e54";
	logging-data="4160310"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18jXMzXK1ojTZVvasARJK8q"
User-Agent: Evolution 3.56.2 (3.56.2-1.fc42)
Cancel-Lock: sha1:d7bmgX9ms0BSYE6gZWfOBtRet7A=
In-Reply-To: <103jimj$3g1be$1@dont-email.me>

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

The above is read like tolling.

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

The problem of 'new' C++ is that rare real innovation but lots about specif=
ic
kinds of functions that are already covered by various kinds of libraries..=
...
C++ seems mostly interested in making existing technique convenient and 'on=
========== REMAINDER OF ARTICLE TRUNCATED ==========