Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++20: Building a Thread-Pool with Coroutines

blog.eiler.eu

Post reply on HN
Print view View original

41–50 of 63 posts

Re: C++20: Building a Thread-Pool with Coroutines

#41

Post by pjmlp »

tialaramex wrote: post #40
pjmlp wrote: post #31

Earlier quoted context omitted.

Lack of concepts was the reason, it will only get better now.

So far as I can see in 2026 the C++ programmers will be assuring us that (some feature from C++26) is going to fix all the awful clag in the C++23 programs which, in turn, offered (some feature from C++23, maybe it's a simpler exception mechanism) but alas instead created more clag, despite their promise to clear up the mess from C++20... I am an old man, and so I remember when left and right every C++ programmer was…

I see it differently.

Many will keep hating C++, while ignoring that Java, .NET (C#, F#, VB, C++/CLI), Python, JavaScript, PHP, Ruby,.... all suffer from similar complexity, spread around 30 - 40 years of language evolution and ecosystems.

Others will cling to their outdated toolchains because the language owners played a Python 3 on them.

While some will understand that the world isn't perfect and make do with what is out there.

Re: C++20: Building a Thread-Pool with Coroutines

#42

Post by pjmlp »

sannysanoff wrote: post #9

I used similar thing, baked on top of cppcoro library (wonderful thing). My application is heavily threaded with hundreds of thousands of short-lived micro-tasks, it's interpreter of highly-parallel expressions, and values are large matrices containing expressions, so it's highly parallelizable. I moved to C++ coroutines from composable futures (CF) library that had few thread pool implementations if memory serves (a…

Well, they have been central to WinRT since the early days, and it was Microsoft input that largely contributed to the design.

So more an issue of tooling than anything else.

Re: C++20: Building a Thread-Pool with Coroutines

#43

Post by pjmlp »

jerf wrote: post #19
sys_64738 wrote: post #7

GO style co-routines and native JSON support would pretty much consign GO to history, IMO.

If things could be "consigned to history" by C++ adding more features, there'd hardly be any other languages left! It has all the features. That's its biggest problem.

Usually only C++ gets the blame, but that is only because most don't pay attention to other language's reference manuals and standard libraries.

I love to pick on Python for such examples, because it is considered to be the new BASIC, yet when I pick the standard language reference + standard library, the amount of pages outgrows those of ISO C++.

Then there is the list of breaking changes that have happened even across minor versions since Python 1.0.

Re: C++20: Building a Thread-Pool with Coroutines

#44

Post by tialaramex »

pjmlp wrote: post #41
tialaramex wrote: post #40

Earlier quoted context omitted.

So far as I can see in 2026 the C++ programmers will be assuring us that (some feature from C++26) is going to fix all the awful clag in the C++23 programs which, in turn, offered (some feature from C++23, maybe it's a simpler exception mechanism) but alas instead created more clag, despite their promise to clear up the mess from C++20... I am an old man, and so I remember when left and right every C++ programmer was…

I see it differently. Many will keep hating C++, while ignoring that Java, .NET (C#, F#, VB, C++/CLI), Python, JavaScript, PHP, Ruby,.... all suffer from similar complexity, spread around 30 - 40 years of language evolution and ecosystems. Others will cling to their outdated toolchains because the language owners played a Python 3 on them. While some will understand that the world isn't perfect and make do with what…

ISO C++ strongly resists simplification. It can grow. I have no doubt that every brilliant idea I see in programming languages can be added to C++ but the problem is that it can't shrink and so what happens instead is that mostly "C++ programmers" speak a dialect of C++ and those dialects become mutually incomprehensible, and so then what was the benefit of C++ as a language rather than just the abstract agreement that you could, in principle, graft every conceivable feature on to something that looks kinda like C?

An example is right in the name. Today we know that "clever" operators like the pair of ++ increment operators in C++ are a bad idea. They too easily allow mistakes to hide in plain sight, the programmer writes ++n where they actually needed n++ or vice versa, and a reviewer's brain overlooks this and so it gets shipped.

If you're playing Code Golf then these operators are a big benefit, but we aren't playing Code Golf, we're writing actual software that will be used in the real world, so explicitly spelling out what you meant is good.

As a result some modern languages deliberately do not have these operators. And e.g. as I understand it Swift actually removed these operators from the language. But C++ 20 still has both operators of course, it's just that your local dialect might forbid one or both of them.

Re: C++20: Building a Thread-Pool with Coroutines

#45

Post by pjmlp »

tialaramex wrote: post #44
pjmlp wrote: post #41

Earlier quoted context omitted.

I see it differently. Many will keep hating C++, while ignoring that Java, .NET (C#, F#, VB, C++/CLI), Python, JavaScript, PHP, Ruby,.... all suffer from similar complexity, spread around 30 - 40 years of language evolution and ecosystems. Others will cling to their outdated toolchains because the language owners played a Python 3 on them. While some will understand that the world isn't perfect and make do with what…

ISO C++ strongly resists simplification. It can grow . I have no doubt that every brilliant idea I see in programming languages can be added to C++ but the problem is that it can't shrink and so what happens instead is that mostly "C++ programmers" speak a dialect of C++ and those dialects become mutually incomprehensible, and so then what was the benefit of C++ as a language rather than just the abstract agreement t…

Modern languages start from scratch.

Python 3 will stay in history as a canonical example of what happens when those wishes turn into reality.

Re: C++20: Building a Thread-Pool with Coroutines

#46

Post by bluGill »

tialaramex wrote: post #40
pjmlp wrote: post #31

Earlier quoted context omitted.

Lack of concepts was the reason, it will only get better now.

So far as I can see in 2026 the C++ programmers will be assuring us that (some feature from C++26) is going to fix all the awful clag in the C++23 programs which, in turn, offered (some feature from C++23, maybe it's a simpler exception mechanism) but alas instead created more clag, despite their promise to clear up the mess from C++20... I am an old man, and so I remember when left and right every C++ programmer was…

That is the way of everything in the world.

Re: C++20: Building a Thread-Pool with Coroutines

#47

Post by varispeed »

pjmlp wrote: post #28
ptr wrote: post #27

Does anyone know when Coroutines are expected to show up in compilers without enabling experimental flags?

Today on Visual C++ 2019.

I am so out of touch with C++. Can you cross compile to Linux on VC++? Does VC++ support MCUs like STM32?

Re: C++20: Building a Thread-Pool with Coroutines

#48

Post by harikb »

Matthias247 wrote: post #23
harikb wrote: post #14

Earlier quoted context omitted.

Main problems with async await model is that the callee decides whether something should run sync/async. In goroutines model, caller decides

I don't think so. coroutine awaits are just like normal function calls in Go (since all of Go functions are implicitely suspendable). I guess you meant the "go" statement? That is more of a coroutine spawn thing, and this would be a separate function in C++ too.

> since all of Go functions are implicitely suspendable

Right. we are saying the same thing about Go. The comparison was with those languages that have explicit async keyword.

Post reply on HN