Re: We have a new standard!

On 30/12/2024 12:25, Michael S wrote:

On Sun, 29 Dec 2024 14:51:17 +0100
David Brown <david.brown@hesbynett.no> wrote:
 

On 29/12/2024 10:32, Muttley@dastardlyhq.com wrote:

On Sat, 28 Dec 2024 16:20:57 +0100
David Brown <david.brown@hesbynett.no> gabbled:

On 28/12/2024 11:19, Muttley@dastardlyhq.com wrote:

Being serious, I haven't even checked whats new in it but going
by C++ 2020
it'll be yet more syntactic soup to support features absolutely
no one outside
of ivory tower academic discussions asked for. It'll just add yet
morecomplexity to compilers, hence more potential bugs and make
the C++ learning
curve even steeper meaning yet more new programmers abandon it -
or don't
even start - for languages such as Python.
 

>
Ah, yes - the classic well-reasoned argument.  Why would one ever
want to /look/ at the new standard before condemning it?

>
Ah yes, the same logic that has produced cars with ever more,
harder to use complexity that no one wants.

>
No, not remotely.  But then, you knew that before making what you
mistakenly thought was a smart or witty reply.
>
If you don't like the complexity of newer C++ standards, that's fine.
If you don't think it is a good direction for the language, fair
enough. You can choose a different language, or stick to an older
standard, or make your own language, or get involved in the C++
standardisation processes and try to influence them.
>
You can have an informed opinion about C++, and agree or disagree
with the opinions of the committee members.
>
But what you don't get to do - or at least, don't get to do if you
want to be viewed seriously - is spout an /uninformed/ opinion.
That's no more than mindless prejudice, and of no interest to anyone.
>
So go away, and read about C++23.  Learn what is new or changed.
/Then/ you can come back and tell us what you don't like about it -
or perhaps you'll find some things that you /do/ like about it.
Either way, you'll be at least vaguely qualified to express an
opinion on it.
>
<https://en.wikipedia.org/wiki/C%2B%2B23>
>

 Comments after cursory view:
 C++20 introduces two promising language features - concepts and
coroutines. Both were introduces without proper support in standard
library. Absence of support in library in both cases was justified by
probably correct claim that the best library constructs are still in
research state, non-crystallized. The hope was that universal
availability of this features at compiler level will help to best
library constructs to mature.
 In case of coroutines developers were left with choice of 3 options:
1. To write a lot of boiler-plate code each time they a going to use
coroutines.
2. To try to organize repetitive patterns in the library (likely
template library) of their own and reuse it between parts of the
programs and multiple projects. Hopefully, share with community.
Hopefully, under liberal license.
3. Don't use coroutines
 In case of concepts, the choice was even narrower:
1. Use concepts when you occasionally are writing container-like or
algorithm-like template of your own.
2. Don't use concepts.
 Nobody was realistically expecting that grassroots developers will use
concepts to develop comprehensive widely reusable library that
duplicates functionality of STL, but brings advantage of sane error
messages.
  So, where we are 3 years later?
W.r.t. concepts, in the same unfortunate place.
W.r.t. coroutines, library provides std::generator. I didn't look at it
yet. Hopefully, it works. Hopefully it is easy to use. But it is just
one of many possible uses of coroutines, and I would think that
it is not the one that could be considered most common.
  Did I miss something?
 

Disclaimer - my work is mostly with long-running projects, and the standard to use is generally set at the start and left unchanged (I have a couple of projects that are still "live" written in C90).  So C++17 is the latest C++ version I have used in real work.  Additionally, working with small embedded systems means I use a somewhat restricted subset of the language and a very restricted subset of the standard library.  So while I try to learn about newer standards, my experience of some features is limited.
I would say that the major changes in C++20 are concepts, coroutines, modules and ranges.  So there was actually quite a lot there.
I like the idea of concepts.  The syntax is somewhat ugly, but the little I have tried so far has been good.  It's a lot nicer than enable_if<>, and it seems to live up to the promise of less horrible error messages from templates.
(There seems to be an inevitable issue with C++, since everything has to be squeezed into a base syntax that dates back to C and was designed long before modern C++ ideas, that syntax will be ugly and at least some new features take a lot of effort to understand.  I wonder if anything will come of the "Cpp2" project, aiming to re-do C++ with a newer syntax?)
I also like the idea of modules, but implementation has taken longer than most C++20 features.  I look forward to trying them now that there is an "official" gcc 14 toolchain package for embedded ARM.
I have no experience with coroutines, so I can't really judge them. They do not appear to me to be a "thread alternative" - rather, they are trying to get the kind of lightweight asynchronous support that is increasingly popular in other languages (Python, Go, Javascript, etc.). Like C++ threading, locks and atomics, they don't really fit in the kind of system I work with.
Ranges can be a good way to express some things in code, but again are somewhat crippled by a very verbose syntax compared to, say, list comprehensions in Python.  (I don't know how something better could have been made and still fit within C++.)
std::format is another major library addition.
Most of the rest of C++20 was evolutionary, rather than revolutionary.
As for C++23, I think most of the changes are small, but some of them will be very useful.  Once "import std;" is properly supported by common toolchains, that will be a very nice feature that pretty much justifies the whole modules feature.
For those that like ranges, the "views" library gives lazy evaluation. Many people who deal with non-ASCII characters will appreciate named UTF-8 characters.  The multi-dimensional [] operator is something people have wanted since the first version of C++.
As a fan of std::optional<> and std::variant<>, I think std::expected<> is a natural addition.  I hope to see that as common practice instead of exceptions, which do not fit well with my line of work.
I expect that the next big project I start on will use C++23, to pick up some of these small improvements.  I don't expect to use more than a small fraction of the new C++23 features - but then, I never use more than a fraction of C++ features.
Features I am looking forward to in the future are contracts, reflection / metaprogramming, pattern matching, and perhaps static exceptions. They keep getting delayed, unfortunately.