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: Sat, 28 Jun 2025 15:16:07 +0800
Organization: A noiseless patient Spider
Lines: 91
Message-ID: <000320c47183f2c6b9e5791d00d680f0a49c35d0.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sat, 28 Jun 2025 09:16:08 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b79204b0ebef8fa28c9a803dae9806f1";
	logging-data="778494"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18jFn8I+LwiZ1O6pzFCDQyp"
User-Agent: Evolution 3.56.2 (3.56.2-1.fc42)
Cancel-Lock: sha1:IFS5jvRNgL1QuaMVnPJU+TvRNQM=
In-Reply-To: <103lm60$22hd$1@dont-email.me>

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 about sp=
ecific
> > kinds of functions that are already covered by various kinds of librari=
es....
> > 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 dev=
eloping'.
> >=20
>=20
> I think it is a good thing that the language is making existing=20
> techniques and code more convenient - that's better for the developer=20
> 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.=20
> =C2=A0From C++11 onwards, it has changed from being "safer C with classes=
"=20
> into a language with increasing support for functional programming=20
> styles (lambdas, ranges), more generic programming (auto, more=20
> templates), compile-time programming (constexpr, consteval),=20
> requirements specifications (concepts, static assertions),=20
> multi-threading (threads, locks), asynchronous programming (coroutines),=
=20
> etc.
>=20
> C++26 continues that trend - improving a number of existing techniques,=
=20
> and adding significant new ones (reflection and contracts).

What about if I say those many (not all) are 'programming style', ie. C++=
=20
invents 'standard' programming style while its propaganda says C++ is a  =
=20
"multi-lingual" language?

> You are right that it does not tackle the "big" things like graphics=20
> libraries.=C2=A0 Attempts to add networking have stalled AFAIUI.=C2=A0 In=
=20
> 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++ shoul=
d=20
> have these things in its standard library.=C2=A0 Python can have these,=
=20
> because Python is already huge and works on only a small number of=20
> platforms - basically, *nix and Win32/Win64.=C2=A0 C++ needs to be useabl=
e on=20
> a very much wider range of platforms now and in the future.=C2=A0 How can=
 you=20
> have a truly portable networking standard library in C++ when there are=
=20
> dozens of networking stacks in use?=C2=A0 How can you have a standard=20
> graphics library for C++ when there are hundreds of graphics libraries=
=20
> used by C++ programmers, some of which are orders of magnitude bigger=20
> development projects than current standard C++?
>=20
> =C2=A0From the users' viewpoint, having more "big" features in a standard=
=20
> library for a language can often be a good thing.=C2=A0 I think there cou=
ld=20
> be a lot of benefits from a repository project for quality=20
> cross-platform libraries for C++.=C2=A0 Boost is the nearest we have, but=
 it=20
> is under-funded, inconsistent, poorly maintained, has jumbled=20
> dependencies, and poor quality control.=C2=A0 A real solution here would =
take=20
> considerable financial backing, because it would be a huge amount of work=
..

There could be 'standard way' of programming for some well defined applicat=
ions
(but, why not inventing it earlier?).
C++ seems developing toward supporting specific applications directly, and=
=C2=A0
steering away from system programming (it is not easy for C++ to write=C2=
=A0
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
> > Duplicates are no good to portability, reusability....
> >=20
>=20