Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #121305 > unrolled thread

Re: We have a new standard!

Back to article view | Back to comp.lang.c++

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: We have a new standard! Sam <sam@email-scan.com> - 2024-12-27 21:51 -0500
    Re: We have a new standard! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-27 20:11 -0800
    Re: We have a new standard! Muttley@dastardlyhq.com - 2024-12-28 10:19 +0000
      Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2024-12-28 16:20 +0100
        Re: We have a new standard! Muttley@dastardlyhq.com - 2024-12-29 09:32 +0000
          Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2024-12-29 14:51 +0100
            Re: We have a new standard! Muttley@dastardlyhq.com - 2024-12-29 16:16 +0000
              Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2024-12-30 08:34 +0100
                Re: We have a new standard! Muttley@dastardlyhq.com - 2024-12-30 09:34 +0000
                  Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2024-12-30 15:37 +0100
                    Re: We have a new standard! Muttley@DastardlyHQ.org - 2024-12-30 15:08 +0000
                      Re: We have a new standard! James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-12-30 18:06 -0500
                      Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-01 17:55 +0200
                        Re: We have a new standard! Muttley@dastardlyhq.com - 2025-01-01 16:05 +0000
            Re: We have a new standard! Paavo Helde <eesnimi@osa.pri.ee> - 2024-12-30 00:12 +0200
              Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2024-12-30 00:44 +0200
                Re: We have a new standard! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-30 03:17 -0800
                  Re: We have a new standard! boltar@caprica.org - 2024-12-30 12:00 +0000
                    Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2024-12-30 15:52 +0100
                    Re: We have a new standard! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-30 18:06 -0800
                Re: We have a new standard! Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2024-12-30 22:26 -0500
              Re: We have a new standard! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-30 03:14 -0800
                Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2024-12-30 16:05 +0100
                Re: We have a new standard! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-30 16:02 -0800
                  Re: We have a new standard! Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-30 17:58 -0800
                    Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2024-12-31 10:54 +0100
                      Re: We have a new standard! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-31 13:40 -0800
            Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2024-12-30 13:25 +0200
              Re: We have a new standard! David Brown <david.brown@hesbynett.no> - 2024-12-30 17:15 +0100
                Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2025-01-04 21:40 +0200
      Re: We have a new standard! Phillip <nntp@fulltermprivacy.com> - 2024-12-28 13:05 -0500
        Re: We have a new standard! Muttley@dastardlyhq.com - 2024-12-29 09:43 +0000
          Re: We have a new standard! Sam <sam@email-scan.com> - 2024-12-29 08:50 -0500
            Re: We have a new standard! wij <wyniijj5@gmail.com> - 2024-12-29 22:33 +0800
              Re: We have a new standard! Muttley@dastardlyhq.com - 2024-12-29 16:17 +0000
                Re: We have a new standard! wij <wyniijj5@gmail.com> - 2024-12-30 01:08 +0800
                  Re: We have a new standard! Muttley@dastardlyhq.com - 2024-12-29 17:11 +0000
            Re: We have a new standard! Muttley@dastardlyhq.com - 2024-12-29 16:15 +0000
              Re: We have a new standard! Sam <sam@email-scan.com> - 2024-12-29 11:57 -0500
                Re: We have a new standard! Muttley@dastardlyhq.com - 2024-12-29 17:08 +0000
                Re: We have a new standard! Michael S <already5chosen@yahoo.com> - 2024-12-29 19:50 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#121351

Michael S wrote:
> On Mon, 30 Dec 2024 00:12:31 +0200
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
> 
>> On 29.12.2024 15:51, David Brown wrote:
>>
>>> 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.  
>>
>> Thanks David, for standing against the trolls. It's a pity that
>> personal freedoms are often interpreted as "my ignorant opinion has
>> exactly the same worth as your expert knowledge".
>>
>> I'm all for personal freedoms, but my freedoms end where they might
>> hurt other people, or the nature for that matter. Boasting ignorant
>> jumble can easily do that.
>>
> 
> It seems that Muttley@dastardlyhq.com still didn't figure out why
> stating strong opinion about something that you not just didn't learn
> in depth, but didn't even look at casually is less than optimal.
> 
Tried to apply your principle by not opining on US tax code before learning it
in depth. Neither worked.

-Pavel

[toc] | [prev] | [next] | [standalone]

#121336

Paavo Helde <eesnimi@osa.pri.ee> writes:

> On 29.12.2024 15:51, David Brown wrote:
>
>> 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.
>
> Thanks David, for standing against the trolls.  It's a pity that
> personal freedoms are often interpreted as "my ignorant opinion has
> exactly the same worth as your expert knowledge".
>
> I'm all for personal freedoms, but my freedoms end where they might
> hurt other people, or the nature for that matter.  Boasting ignorant
> jumble can easily do that.

I agree with much of what you say.  I don't agree with the last
sentence.  Depending on other factors, a public broadcast of a
personal statement can produce enough of a negative effect so that
it should be prohibited, but simply boasting ignorant jumble does
not, by itself, fall into that category.  The nature of posting to
a newsgroup like this one does nothing to change that.

Personal opinion:  the comments from David Brown do more harm than
good here.  At some level he is just a guilty of giving a preachy
opinion as the person he is responding to.  It seems likely that
his statements will exacerbate the offending behavior rather than
diminish it.

[toc] | [prev] | [next] | [standalone]

#121344

On 30/12/2024 12:14, Tim Rentsch wrote:

> Personal opinion:  the comments from David Brown do more harm than
> good here.  At some level he is just a guilty of giving a preachy
> opinion as the person he is responding to.  It seems likely that
> his statements will exacerbate the offending behavior rather than
> diminish it.

Opinion noted.

I disagree that I was giving a "preachy /opinion/", but I can accept 
that my posts were somewhat "preachy" in style.  What influence it may 
have on Muttley (or anyone else giving unjustified opinions on a 
standard they have not looked at) remains to be seen - I don't think 
anyone is in a position to predict accurately.

(I don't always agree with such feedback, but I do always try to give it 
fair consideration.)

Perhaps we can have a more topical discussion about the actual changes 
and new features in C++23?

[toc] | [prev] | [next] | [standalone]

#121348

On 12/30/2024 3:14 AM, Tim Rentsch wrote:
[...]
> Personal opinion:  the comments from David Brown do more harm than
> good here.  At some level he is just a guilty of giving a preachy
> opinion as the person he is responding to.  It seems likely that
> his statements will exacerbate the offending behavior rather than
> diminish it.

I had some arguments with David Brown. Everything was rather cordial. No 
flame wars, or anything like that.

[toc] | [prev] | [next] | [standalone]

#121349

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> On 12/30/2024 3:14 AM, Tim Rentsch wrote:
> [...]
>
>> Personal opinion:  the comments from David Brown do more harm than
>> good here.  At some level he is just a guilty of giving a preachy
>> opinion as the person he is responding to.  It seems likely that
>> his statements will exacerbate the offending behavior rather than
>> diminish it.
>
> I had some arguments with David Brown.  Everything was rather
> cordial.  No flame wars, or anything like that.

Please note that my comments were not about David Brown in general
but only about the statements of his that were quoted in the posting
I was responding to.  What I said was not meant as a general
statement, only a specific one, and was not meant about David as a
person but only about the (quoted) words that appeared in the
posting.

[toc] | [prev] | [next] | [standalone]

#121352

On 31/12/2024 02:58, Tim Rentsch wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> 
>> On 12/30/2024 3:14 AM, Tim Rentsch wrote:
>> [...]
>>
>>> Personal opinion:  the comments from David Brown do more harm than
>>> good here.  At some level he is just a guilty of giving a preachy
>>> opinion as the person he is responding to.  It seems likely that
>>> his statements will exacerbate the offending behavior rather than
>>> diminish it.
>>
>> I had some arguments with David Brown.  Everything was rather
>> cordial.  No flame wars, or anything like that.

(I have been less than cordial with some people - sometimes to an extent 
that I later regretted.)

> 
> Please note that my comments were not about David Brown in general
> but only about the statements of his that were quoted in the posting
> I was responding to.  What I said was not meant as a general
> statement, only a specific one, and was not meant about David as a
> person but only about the (quoted) words that appeared in the
> posting.

And that's all fine by me.


"""
Well, sir, my friends praise me and in so doing make a fool of me, while 
my enemies tell me plainly that I am a fool. Therefore my enemies help 
me gain knowledge of myself, while my friends deceive me.
"""

Twelfth Night



(Not that I view Tim as "my enemy" in any sense!)

[toc] | [prev] | [next] | [standalone]

#121353

On 12/31/2024 1:54 AM, David Brown wrote:
> On 31/12/2024 02:58, Tim Rentsch wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>
>>> On 12/30/2024 3:14 AM, Tim Rentsch wrote:
>>> [...]
>>>
>>>> Personal opinion:  the comments from David Brown do more harm than
>>>> good here.  At some level he is just a guilty of giving a preachy
>>>> opinion as the person he is responding to.  It seems likely that
>>>> his statements will exacerbate the offending behavior rather than
>>>> diminish it.
>>>
>>> I had some arguments with David Brown.  Everything was rather
>>> cordial.  No flame wars, or anything like that.
> 
> (I have been less than cordial with some people - sometimes to an extent 
> that I later regretted.)

Afaict, it basically goes up to, shit happens? The fact that you 
regretted some of them means you are a good person at heart. I think, 
perhaps, that we all have been there wrt regretting something on the 
Wild World of Usenet. ;^)

Happy New Year, David!

:^)


>> Please note that my comments were not about David Brown in general
>> but only about the statements of his that were quoted in the posting
>> I was responding to.  What I said was not meant as a general
>> statement, only a specific one, and was not meant about David as a
>> person but only about the (quoted) words that appeared in the
>> posting.
> 
> And that's all fine by me.
> 
> 
> """
> Well, sir, my friends praise me and in so doing make a fool of me, while 
> my enemies tell me plainly that I am a fool. Therefore my enemies help 
> me gain knowledge of myself, while my friends deceive me.
> """
> 
> Twelfth Night
> 
> 
> 
> (Not that I view Tim as "my enemy" in any sense!)

Indeed.

[toc] | [prev] | [next] | [standalone]

#121338

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?

[toc] | [prev] | [next] | [standalone]

#121346

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.

[toc] | [prev] | [next] | [standalone]

#121417

On Mon, 30 Dec 2024 17:15:43 +0100
David Brown <david.brown@hesbynett.no> wrote:

> 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:
> >   
> > 
> > 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?
> >   
> 

<snip>

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


The version of coroutines that founded its way into C++ has its roots
in C# (or may be in F#, but  F# being primarily functional, is so
different that it's hard to be sure). Actually, in C# they appeared
first under not particularly illuminating name 'Iterators' (a.k.a.
IEnumerable<T>) and later on as a part of Async/Await pattern. Python
and Javascript (and Swift and Rust? I am not sure about it.) borrowed
from C#. Go goroutines (that were very recently borrowed by Java under
the name 'virtual threads') are quite different.

Although it is true that main motivation of people that initiated
inclusion of coroutines in C++ is implementation of of async/await and
of "iterators" (in C++, following Python, I suppose, they are named
'generators') they certainly can be used for other things too. 
In particular, C++ coroutines can be utilized for implementing things
that today tend to be written as state machines, in almost sequential
coding style. In this role they look like a useful tool for "neither
big nor tiny" sort of embedded software that, according to my
understanding, happens to be the job that pays your bills.

Originally, I wanted to give an example of bit-banging implementation
of monitoring of pair of different I2C temperature sensors attached to
independent buses, written as a couple of C++ coroutines called from
one low-priority task of real-time executive. But then I reconsidered.
It's to much work and unlikely to be read by many. Plus, I am rather
bad writer.
May be, later I'd give simpler examples of what I mean.
Or, preferably, you and other readers figure it out by yourselves. The
latter is better pedagogically. That is, except for myself.

[toc] | [prev] | [next] | [standalone]

#121311

On 12/28/24 05:19, Muttley@dastardlyhq.com wrote:
> On Fri, 27 Dec 2024 21:51:10 -0500
> Sam <sam@email-scan.com> gabbled:
>> Stefan Ram writes:
>>
>>>   According to one web site, C++23 (ISO/IEC 14882:2024) was released
>>>   October 19, 2024.
>>>
>>>   (Sorry if it was mentioned here then, and I just did not notice!)
>>
>> Hip-hip-hooray! Finally, finally they addressed the long-standing 
>> criticism of C++ being too trivial and too simple, and a kids' 
>> language. At last, there's some meat on those bones. Watch out, Java! 
>> There's a new boss in town. Real programming languages' specifications 
>> are measured in pounds, and not a page count.
> 
> Watch out Java? Watch out Perl more like! The title of most write only
> language could soon change!
> 
> 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.
> 

I'm still on C++98 and C++03. Everything beyond that is just bloat to 
me. ;-)

[toc] | [prev] | [next] | [standalone]

#121319

On Sat, 28 Dec 2024 13:05:37 -0500
Phillip <nntp@fulltermprivacy.com> gabbled:
>On 12/28/24 05:19, Muttley@dastardlyhq.com wrote:
>> On Fri, 27 Dec 2024 21:51:10 -0500
>> Sam <sam@email-scan.com> gabbled:
>>> Stefan Ram writes:
>>>
>>>>   According to one web site, C++23 (ISO/IEC 14882:2024) was released
>>>>   October 19, 2024.
>>>>
>>>>   (Sorry if it was mentioned here then, and I just did not notice!)
>>>
>>> Hip-hip-hooray! Finally, finally they addressed the long-standing 
>>> criticism of C++ being too trivial and too simple, and a kids' 
>>> language. At last, there's some meat on those bones. Watch out, Java! 
>>> There's a new boss in town. Real programming languages' specifications 
>>> are measured in pounds, and not a page count.
>> 
>> Watch out Java? Watch out Perl more like! The title of most write only
>> language could soon change!
>> 
>> 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.
>> 
>
>I'm still on C++98 and C++03. Everything beyond that is just bloat to 
>me. ;-)

I would say that C++ 11 did improve things particularly wrt the STL and
possibly 2014 was the high point. Beyond that its been as you say pointless
bloat that achieves nothing.

[toc] | [prev] | [next] | [standalone]

#121320

Muttley@dastardlyhq.com writes:

> On Sat, 28 Dec 2024 13:05:37 -0500
> Phillip <nntp@fulltermprivacy.com> gabbled:
>> I'm still on C++98 and C++03. Everything beyond that is just bloat to me. ;-)
>
> I would say that C++ 11 did improve things particularly wrt the STL and
> possibly 2014 was the high point. Beyond that its been as you say pointless
> bloat that achieves nothing.

I would say that C++17 was also an incremental improvement.

But C++20 jumped the shark, when the standardization process was hijacked by  
Microsoft in order to cram coroutines into the language, which noone wanted,  
cared, or asked for, simply because the standard threading model in Windows  
blows chunks, performance wise, and Microsoft desperately needed a  
multithreading model that did not suck.

And things went downhill from that point on…

[toc] | [prev] | [next] | [standalone]

#121323

On Sun, 2024-12-29 at 08:50 -0500, Sam wrote:
> Muttley@dastardlyhq.com writes:
> 
> > On Sat, 28 Dec 2024 13:05:37 -0500
> > Phillip <nntp@fulltermprivacy.com> gabbled:
> > > I'm still on C++98 and C++03. Everything beyond that is just bloat to me. ;-)
> > 
> > I would say that C++ 11 did improve things particularly wrt the STL and
> > possibly 2014 was the high point. Beyond that its been as you say pointless
> > bloat that achieves nothing.
> 
> I would say that C++17 was also an incremental improvement.
> 
> But C++20 jumped the shark, when the standardization process was hijacked by  
> Microsoft in order to cram coroutines into the language, which noone wanted,  
> cared, or asked for, simply because the standard threading model in Windows  
> blows chunks, performance wise, and Microsoft desperately needed a  
> multithreading model that did not suck.
> 
> And things went downhill from that point on…
> 

Basically, c++ standard or standardization is political. There are lots of 
standard committee members' 'old software' to maintain. There is nothing wrong
with that. The wrong thing is regarding it as better new technology, especially
when libwy is more advanced (idea) than c++standard library by one generation.

[toc] | [prev] | [next] | [standalone]

#121326

On Sun, 29 Dec 2024 22:33:05 +0800
wij <wyniijj5@gmail.com> gabbled:
>with that. The wrong thing is regarding it as better new technology, especi=
>ally
>when libwy is more advanced (idea) than c++standard library by one generati=
>on.

Nobody gives a rats arse about your library. Haven't you figured that out yet?

[toc] | [prev] | [next] | [standalone]

#121328

On Sun, 2024-12-29 at 16:17 +0000, Muttley@dastardlyhq.com wrote:
> On Sun, 29 Dec 2024 22:33:05 +0800
> wij <wyniijj5@gmail.com> gabbled:
> > with that. The wrong thing is regarding it as better new technology, especi=
> > ally
> > when libwy is more advanced (idea) than c++standard library by one generati=
> > on.
> 
> Nobody gives a rats arse about your library. Haven't you figured that out yet?
> 

No problem for me. I just see you people suffering there, maybe enjoying.

[toc] | [prev] | [next] | [standalone]

#121330

On Mon, 30 Dec 2024 01:08:29 +0800
wij <wyniijj5@gmail.com> gabbled:
>On Sun, 2024-12-29 at 16:17 +0000, Muttley@dastardlyhq.com wrote:
>> On Sun, 29 Dec 2024 22:33:05 +0800
>> wij <wyniijj5@gmail.com> gabbled:
>> > with that. The wrong thing is regarding it as better new technology, es=
>peci=3D
>> > ally
>> > when libwy is more advanced (idea) than c++standard library by one gene=
>rati=3D
>> > on.
>>=20
>> Nobody gives a rats arse about your library. Haven't you figured that out=
> yet?
>>=20
>
>No problem for me. I just see you people suffering there, maybe enjoying.

Having seen some examples of your code I think the suffering would be for
anyone stupid enough to try and use your library.

[toc] | [prev] | [next] | [standalone]

#121324

On Sun, 29 Dec 2024 08:50:16 -0500
Sam <sam@email-scan.com> gabbled:
>Muttley@dastardlyhq.com writes:
>
>> On Sat, 28 Dec 2024 13:05:37 -0500
>> Phillip <nntp@fulltermprivacy.com> gabbled:
>>> I'm still on C++98 and C++03. Everything beyond that is just bloat to me.
>;-)
>>
>> I would say that C++ 11 did improve things particularly wrt the STL and
>> possibly 2014 was the high point. Beyond that its been as you say pointless
>> bloat that achieves nothing.
>
>I would say that C++17 was also an incremental improvement.

I'll give you shared_mutex that came with 17, but really that should have
been in from 2011 when threading was added. Not having 3 level thread locking 
from the get go was ridiculous. But the rest of 17 ... meh.

>But C++20 jumped the shark, when the standardization process was hijacked by  
>Microsoft in order to cram coroutines into the language, which noone wanted,  
>cared, or asked for, simply because the standard threading model in Windows  
>blows chunks, performance wise, and Microsoft desperately needed a  
>multithreading model that did not suck.

I looked at co-routines and wondered wtf the author(s) was smoking. How its
supposed to be simpler than simply using a local state machine beats the fsck 
out of me.

[toc] | [prev] | [next] | [standalone]

#121327

Muttley@dastardlyhq.com writes:

> On Sun, 29 Dec 2024 08:50:16 -0500
> Sam <sam@email-scan.com> gabbled:
>> But C++20 jumped the shark, when the standardization process was hijacked by  
>> Microsoft in order to cram coroutines into the language, which noone wanted,  
>> cared, or asked for, simply because the standard threading model in Windows  
>> blows chunks, performance wise, and Microsoft desperately needed a  
>> multithreading model that did not suck.
>
> I looked at co-routines and wondered wtf the author(s) was smoking. How its
> supposed to be simpler than simply using a local state machine beats the  
> fsckout of me.

Everything will make sense to you when you look at the co-routines  
proposal, and note its authorship:

https://isocpp.org/files/papers/N4402.pdf

Visual C++ does not have an impressive track record of zippy adoptions of  
new C++ language feature. Most of the time it gets beaten to the punch by  
gcc. Weirdly, it was the first out of the gate with co-routines.

As I said: std::thread blows chunks on Windows. This was Microsoft's  
solution.

[toc] | [prev] | [next] | [standalone]

#121329

On Sun, 29 Dec 2024 11:57:45 -0500
Sam <sam@email-scan.com> gabbled:
>Muttley@dastardlyhq.com writes:
>> I looked at co-routines and wondered wtf the author(s) was smoking. How its
>> supposed to be simpler than simply using a local state machine beats the  
>> fsckout of me.
>
>Everything will make sense to you when you look at the co-routines  
>proposal, and note its authorship:
>
>https://isocpp.org/files/papers/N4402.pdf

Don't know either of the authors but I knew it was MS.

>Visual C++ does not have an impressive track record of zippy adoptions of  
>new C++ language feature. Most of the time it gets beaten to the punch by  
>gcc. Weirdly, it was the first out of the gate with co-routines.
>
>As I said: std::thread blows chunks on Windows. This was Microsoft's  
>solution.

For solution read hack. At best its co-operative multitasking reinstated in
a hideously overcomplicated way requiring nonsense special classes for 
[reasons] when a simple "yield" command would have sufficed.

A proper solution would be to fix whatever fuckups they've made in their
implementation of std::thread unless the problem lies in the windows kernel
itself which frankly wouldn't surprise me.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web