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

On 28/06/2025 19:24, wij wrote:

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

"One language suits all" and "multi-paradigm" are /completely/ different concepts.  Saying C++ is "one language that suits all" is like saying everyone should drive a Toyota Corolla - that one car will suit everyone.  Saying C++ is "multi-paradigm" is like saying a Toyota RAV4 is good for town driving, long distance car vacations, and pulling a horse box.
No one, AFAIK, has ever suggested that C++ is suitable for all tasks, much less a language that suits all people.  It covers a wider range of tasks than most languages, but very far from all.
But there is no doubt that it is a multi-paradigm language.  And there is no doubt that some people choose to write C++ code that is imperative (like C with stronger types and namespaces), most use object oriented programming to some extent (though many have very simple hierarchies), many will do a bit of generic programming.  Some people like functional style with lambdas and ranges, but many do not.
There are limitations to supporting all this.  The syntax for some features can be awkward, and the implementations can be less efficient or less flexible than a more dedicated language of that paradigm.  If you want to do serious function programming, you are better off with a functional programming language - but if you think that part of your C++ code could be better expressed in a functional style, then use that. (People do the same with Python.)

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

Most design decisions in most languages are tradeoffs, with their pros and cons.  You only need to look at the size of the C++ standard to see the major downside - it is a big, complex language, and there are many gotchas.  If you don't think it is worth it, use a different language (and that includes earlier C++ standards as an option - most toolchains continue to support older versions of C++).

Conclusion: What all the efforts are for? Seems only good for experenced user.

Certainly some parts of C++ are primarily used in code by very experienced users.  But that's okay.  Let the more dedicated "C++ wizards" write the code for implementing std::vector<> and the rest. Let /them/ worry about how move semantics work, and when different type traits are needed.  The rest of us can reap the benefits when we /use/ these classes, without having to understand the details.

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

When people write modular code, it's okay that different people use different language features to get the best implementation of their part.  With a big program, you don't expect to understand all of it. This is normal for programming - even if you stick to a relatively small language like C.