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: Sun, 29 Jun 2025 01:24:52 +0800
Organization: A noiseless patient Spider
Lines: 134
Message-ID: <ed95ced7787512b42e76e1fdc84ba215c155c821.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>
	 <c6c7eeec9a6993ca2d49bfadd02fb2162531c939.camel@gmail.com>
	 <103lm60$22hd$1@dont-email.me>
	 <000320c47183f2c6b9e5791d00d680f0a49c35d0.camel@gmail.com>
	 <103p0je$tqje$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sat, 28 Jun 2025 19:24:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b79204b0ebef8fa28c9a803dae9806f1";
	logging-data="988269"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/eZ8tP3imDZD2gj34RRRHF"
User-Agent: Evolution 3.56.2 (3.56.2-1.fc42)
Cancel-Lock: sha1:DL4SBaDDmFb97ZAqT1jk15ZUqA8=
In-Reply-To: <103p0je$tqje$1@dont-email.me>

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:
> > >=20
> > > > The problem of 'new' C++ is that rare real innovation but lots abou=
t specific
> > > > kinds of functions that are already covered by various kinds of lib=
raries....
> > > > C++ seems mostly interested in making existing technique convenient=
 and 'only'
> > > > dealing with 'small' (or part of) problems (e.g. avoiding to deal w=
ith graphics
> > > > or provide basic facilities).
> > > > But, nothing in all is actually wrong with the above, if C++ is 'in=
 developing'.
> > > >=20
> > >=20
> > > 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.
> > >=20
> > > But C++ has also evolved to allow very different kinds of techniques.
> > > =C2=A0=C2=A0From C++11 onwards, it has changed from being "safer C wi=
th 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 (coroutine=
s),
> > > etc.
> > >=20
> > > C++26 continues that trend - improving a number of existing technique=
s,
> > > and adding significant new ones (reflection and contracts).
> >=20
> > 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?
>=20
> I'm sorry, I don't understand what you are trying to say here.=C2=A0 I th=
ink=20
> the term commonly used is "programming paradigm" - where "imperative",=
=20
> "generic", "functional", "object oriented", etc., are "paradigms".=C2=A0 =
And=20
> sometimes within a single language, these are referred to as=20
> "programming styles".=C2=A0 Often the use of these terms, and the=20
> distinctions between them, are somewhat artificial.
>=20
> My point is just that C++ has evolved to let you write code in=20
> significantly different ways.=C2=A0 If those other ways work better for t=
he=20
> problem you are trying to solve, then that's a good thing.=C2=A0 If they=
=20
> don't, then feel free to ignore them in your code.
>=20

But I think "one language suits all" (multi-paradigm) is a problematic idea=
l.
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 us=
er.

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.=C2=A0 Attempts to add networking have stalled AFAIUI.=C2=
=A0 In
> > > comparison to, say, Python, the standard library is much smaller.
> > >=20
> > > I think this is, for the most part, fine.=C2=A0 I don't believe C++ s=
hould
> > > have these things in its standard library.=C2=A0 Python can have thes=
e,
> > > because Python is already huge and works on only a small number of
> > > platforms - basically, *nix and Win32/Win64.=C2=A0 C++ needs to be us=
eable on
> > > a very much wider range of platforms now and in the future.=C2=A0 How=
 can you
> > > have a truly portable networking standard library in C++ when there a=
re
> > > dozens of networking stacks in use?=C2=A0 How can you have a standard
> > > graphics library for C++ when there are hundreds of graphics librarie=
s
> > > used by C++ programmers, some of which are orders of magnitude bigger
> > > development projects than current standard C++?
> > >=20
> > > =C2=A0=C2=A0From the users' viewpoint, having more "big" features in =
a standard
> > > library for a language can often be a good thing.=C2=A0 I think there=
 could
> > > be a lot of benefits from a repository project for quality
> > > cross-platform libraries for C++.=C2=A0 Boost is the nearest we have,=
 but it
> > > is under-funded, inconsistent, poorly maintained, has jumbled
> > > dependencies, and poor quality control.=C2=A0 A real solution here wo=
uld take
> > > considerable financial backing, because it would be a huge amount of =
work.
> >=20
> > There could be 'standard way' of programming for some well defined appl=
ications
> > (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.
> >=20
>=20
> I disagree.=C2=A0 C++ can be, and is, used for a wide variety of differen=
t=20
> kinds of programming.=C2=A0 Not all aspects of the language and standard=
=20
> library and suitable for all kinds of programming, naturally.
>=20
>=20