Sujet : Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,
De : david.brown (at) *nospam* hesbynett.no (David Brown)
Groupes : comp.lang.c++Date : 27. Jun 2025, 09:53:19
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <103lm60$22hd$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
On 27/06/2025 06:56, wij wrote:
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'.
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.
But C++ has also evolved to allow very different kinds of techniques. From C++11 onwards, it has changed from being "safer C with 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 (coroutines), etc.
C++26 continues that trend - improving a number of existing techniques, and adding significant new ones (reflection and contracts).
You are right that it does not tackle the "big" things like graphics libraries. Attempts to add networking have stalled AFAIUI. In comparison to, say, Python, the standard library is much smaller.
I think this is, for the most part, fine. I don't believe C++ should have these things in its standard library. Python can have these, because Python is already huge and works on only a small number of platforms - basically, *nix and Win32/Win64. C++ needs to be useable on a very much wider range of platforms now and in the future. How can you have a truly portable networking standard library in C++ when there are dozens of networking stacks in use? How can you have a standard graphics library for C++ when there are hundreds of graphics libraries used by C++ programmers, some of which are orders of magnitude bigger development projects than current standard C++?
From the users' viewpoint, having more "big" features in a standard library for a language can often be a good thing. I think there could be a lot of benefits from a repository project for quality cross-platform libraries for C++. Boost is the nearest we have, but it is under-funded, inconsistent, poorly maintained, has jumbled dependencies, and poor quality control. A real solution here would take considerable financial backing, because it would be a huge amount of work.
Duplicates are no good to portability, reusability....