Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: wij 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> <103h604$2s3vq$1@dont-email.me> <103hh5j$2ui1d$1@dont-email.me> <103ivnj$3btbj$1@dont-email.me> <103jimj$3g1be$1@dont-email.me> <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