Path: ...!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c++
Subject: Re: We have a new standard!
Date: Mon, 30 Dec 2024 17:15:43 +0100
Organization: A noiseless patient Spider
Lines: 168
Message-ID: <vkugvg$1n0oa$1@dont-email.me>
References: <C++-20241227154547@ram.dialup.fu-berlin.de>
 <cone.1735354270.316807.177566.1000@ripper.email-scan.com>
 <vkojb7$96o6$1@dont-email.me> <vkp50p$ce10$1@dont-email.me>
 <vkr4ve$sksr$1@dont-email.me> <vkrk4l$10d4e$1@dont-email.me>
 <20241230132544.00005f92@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 30 Dec 2024 17:15:44 +0100 (CET)
Injection-Info: dont-email.me; posting-host="60c17b8524eb9cbd07a8161a28a5c214";
	logging-data="1803018"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/mNSiChs27feOcJgs+AYKTcUfEpEPwDHA="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:sEII3sR9UK53xbHhVn7BwVWGmOA=
In-Reply-To: <20241230132544.00005f92@yahoo.com>
Content-Language: en-GB
Bytes: 8742

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.