Re: "Trip report: June 2025 ISO C++ standards meeting (Sofia,

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:
 

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).

 
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?

 
I'm sorry, I don't understand what you are trying to say here.  I think
the term commonly used is "programming paradigm" - where "imperative",
"generic", "functional", "object oriented", etc., are "paradigms".  And
sometimes within a single language, these are referred to as
"programming styles".  Often the use of these terms, and the
distinctions between them, are somewhat artificial.
 
My point is just that C++ has evolved to let you write code in
significantly different ways.  If those other ways work better for the
problem you are trying to solve, then that's a good thing.  If they
don't, then feel free to ignore them in your code.
 

But I think "one language suits all" (multi-paradigm) is a problematic ideal.
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 user.

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.  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.

 
There could be 'standard way' of programming for some well defined applications
(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.
 

 
I disagree.  C++ can be, and is, used for a wide variety of different
kinds of programming.  Not all aspects of the language and standard
library and suitable for all kinds of programming, naturally.