C++ Club - 164. ADSP, C++ and beyond, GCC, Boost.Async, callables and ranges

Episode Date: August 29, 2023

With Gianluca Delfino, Vladimír Arnošt, Andrew Fodiman, Dmitry Kuzminov, Mikhail Zborovski, Sergey Ishin et al.Notes: https://cppclub.uk/meetings/2023/164/Video: https://youtu.be/mpoqVodkNB0

This is C++ Club 164, which took place on the 10th of August 2023. Right. Let's start with the topic that you suggested, Gianluca. Algorithms and Data Structures podcast mentioned us in episode 136, C++ on C Live. They did mention us in the first couple of minutes and i'm quoting uh bryce is cpp club a real thing and connor says the least subscribed to c++ podcast go subscribe to whatever this is so. So thanks, Connor and Bryce for mentioning us. I mean, that was amazing. I didn't expect they actually

Connor knew we existed. I was very surprised. So thank you very much for the shout out. Yeah, definitely. And you remember the Pirates of the Caribbean, where someone says to Jack Sparrow, you're the worst pirate or captain that I've heard of? To which Jack Sparrow says, ah, but you've heard of me. So, yeah. Good.

That's good. Right. Next one is a new tool, Clang UML. It's a customizable automatic UML diagram generator for C++ based on Clang. So it can generate various diagrams. There are examples on GitHub, like this one, for example, class field and methods. So yeah, the all too familiar style of YML diagrams can be automatically generated from your code. Like this one class inheritance diagram. Looks like the stuff that Doxygen kind of generates. Yeah, yeah, someone did mention that Doxygen kind of generates. Yeah, someone did mention that Doxygen with all the bells and whistles

turned on comes pretty close to this. And someone on Hackanew said, quote, remember the days people thought they could build everything in UML diagrams and have the code essentially be generated or trivially written from there.

Fast forward to 2023 and we are generating UML diagrams from C++ code because it's easier. End quote. I remember when I just started in one of the firms that I was a consultant in, we did use some... was it something like expert.uml or something like that? And we did try to generate code and it was such a hassle. Never done that afterwards. But yeah, the other way around could be useful, especially when looking at an unfamiliar codebase. Right, that's the Hacker News thread about it. Next, as announced, I watched this discussion from the ACCU conference called C++ and Beyond and beyond discussion Vittoria Romeo, Kevlin Henney, Nico Iositis and Kate Gregory. It's an hour and a half and I gathered some quotes. Fair warning, a trigger warning even. This video contains extreme C++ negativity. So if you want to watch it,

beware. Yes. And I thought I'd read some of the quotes that I've assembled. Starting from the introductions, they were, Kate Gregory said,

I'm part of the Carbon Project. Nico Iosifis said, I used to love C++, now I hate it. I proposed this panel because I like to complain. And Vittorio Romeo introduced himself as, I'm the young person of this panel. And then the discussion followed. Vittorio Romeo mentioned epochs as a way to progress C++ evolution combined with modules, like using an epoch per module. And he still thinks this would help. Although, as we've discussed many times, epochs in their

current state, at least, would lead to C++ dialects. Kevlin Henney said, quote, we are accumulating crap and adding more crap. And the committee members don't realize that, because they are solving pet projects and saying no to other things." He said basically that we need another programming language. As if we didn't have any more apart from C++. He probably meant the successor. Nikolai Yosutis said, quote, C++ is fundamentally broken. I don't think we can solve that. I think the committee is not willing to solve that.

And the reason is we have no common sense or common direction. End quote. He said that there is no language, at least currently, that can replace C++. So, this is a dead language for the next 20 years. Wow. Maybe he was in a bad mood. But yeah, he really looked like his puppy dog died the day before. Kate Gregory said, there are some toxic pockets in our community that are celebrated. Hear, hear.

And then no one talked about it again for the duration of the presentation. Nico continued, I sell a hell of a lot of books describing the nonsense and the bullshit we standardized. Well, I'm glad it's working out for him. Vittorio said, quote, I like Rust. I'm sorry if someone feels offended by this statement. End quote. Why would anyone be offended? It's another language. Use it if you like it. He doesn't see Carbon or Cpp2 as viable paths forward for C++. Yeah, that much I agree with. Niko then said, C++ will be in top 5 in 10 years because there is no replacement.

Kevlin Henney says, quote, C++ has got the wrong mechanism for its future evolution, meaning the ISO process. Vittorio Romeo said, some people in the committee, including Bjarne, are against dialects. How can you convince them that we need dialects? End quote. And here we go. It's E epochs again. Also mentioned circle, which changes code meaning per module depending on the attributes or compiler directives. Not ideal.

Bryce says, there is no sense of common ownership in the committee. People are pushing their own papers. We need people to review and discuss other people's papers. Nico says, Usually when we vote on something in the standard, 90% of the people voting have no clue what they are voting on. Yeah, that sounds like quite a big problem. Vittorio says, should we welcome new talent to C++ given how terrible and broken it is,

or should we tell them to stay away and use other languages? You can tell anyone to stay away, but that doesn't mean they will, given how popular C++ is. Kate Gregory mentioned Bjarne's quote about the fact that there are two kinds of languages, the ones that everyone complains about and the ones that no one uses. Vittoria says, quote, I don't mean to sound like a Rust evangelist I like C++ but

and then he goes on praising Rust wow Kate Gregory says I like learning and despite your doom and gloom about how broken C++20 is I've been having a lot of fun learning the new stuff, writing the

new examples, figuring out how it makes code shorter and more expressive." There's a Reddit thread on this video and one of the first quotes is, "...quite surreal to hear them talk about such doom and gloom over the future of C++. And when they say broken, I mean, we can, in the course of the migration right now, actually found one of the things that was broken, migrating from 17 to 20. But what these people were actually referring to in the sense of broken? I guess because they don't get the features they want, and there is no easy way to extend C++ in the way they want it. So it's kind of broken for some people, but it's perfectly okay for others.

And one of the main topics when people talk about how broken C++ is, is that the ABI stability. So because of all the legacy stuff in the language, and the pretty much inability of the committee to break ABI at this point in order to keep backwards compatibility. Some people say that this prevents C++ from progressing and also prevents the committee from fixing the stuff that's broken because that would break backwards compatibility and break tons of code that's broken, because that will break backwards compatibility and break tons of code that's out there. Yeah, my thought from the broken was the stuff discussed on CppCast

was the kind of stuff about always getting the defaults wrong in some of the stuff. There was a paper recently on using lambdas instead of functions because of certain cases of getting the defaults wrong and maybe just the unintended complexity of the combination of features. I guess you need to have a whole book about initialization in C++. I'm sorry, I wouldn't say that people are complaining because they don't see some features in C++. Probably they just lost so many features that C++ has. And on the other side, all this critic stuff is very constructive for me and very useful. For example, the defective C++ by Yossi Krenin

is my go-to tool for every pit holes that I have in C++. So I think critic is very important, and we should pick it up process and probably make C++ better. It will be easier if you know all complaints around. That said, yeah, I would suggest watching the video because as it was excellently summarized by Gleb, they do raise a lot of interesting points, not concluding with many solutions except for epochs.

But the problems that they raise are all very real problems. And again, all concerning process on how to move forward. And so far we have a list of ideas, but none of those widely accepted. So yeah, people advocate for CTP2 or Carbon or Epochs. And nobody agrees. And somebody just would like to see everything being broken, ABI-wise, and start over also with good defaults. But there's a lot of reasons why that's also a bad idea. So that is the problem. That is why... Yeah, very well put.

And the committee has its own problems. Some people say that the ISO process is at fault here. I'm not sure about that. Yeah, me neither, because, you know, definitely they have problems that they also go on about and they explain in this video. And it does sound very reasonable that the process is not ideal. But even if we had a quote-unquote benevolent dictator or anything like that, even if we had a more streamlined approach and and and maybe a more clear vision for the future we still would have to choose between different possibilities none of those will appease everybody so and i don't see a clear way out you know in any way but definitely there's

probably a way of improving the process just to get people to actually read and be more informed when they vote for sure. I would like to say that there are two points of view on the same language because those who develop libraries and those who develop applications, they have opposite views. So C++ is a reasonable language whenever you have a library that is developed already and you just make an application. Vittorio Romeo who works on BSL sees that from the opposite point of view because he needs to support the library that can be used in many different weird ways. And from that perspective, C++ is broken. It is very difficult to support

library in such a way that it would work in those ways. For those who develop applications, the situation is much easier. Yeah, but you would see that there is a lot of reasons to complain also from the user perspective because we have this report from NSA and other government entities that

would say we shouldn't be using C++ for many things because it's not quote-unquote safe. So that affects users mostly. if you were to ask many people, including Vittorio, he would probably argue we could make it safer for everybody, including the user, employing things like epochs, which to an extent is true. Obviously, there is caveats to that.

Yeah. I wonder what NSA would tell about assembler and basically still some stuff being written in assembler. That is banned. That is banned together with C++. I think the white list is short, including probably Rust or a few others that are again, you know, quote unquote safer. But if C++ is out, assembly is also out. Yeah. Another quote from Reddit. At least they're being honest. It's a common perception here that committee-driven development in its current form is a fail. To which Daniela Engert replied,

C++ is exactly as much committee-driven as users want it to be. The C++ committee are to a large degree volunteers that care enough to actually work on C++ and put a substantial amount of their time and money into that work. So yeah, I think the time for having a benevolent dictator, if there was such a time, has long passed and now we are pretty much stuck with the committee. And I remember Bjarne saying that it's very difficult to work with a committee that has like 200 members because you can't get to a consensus easily. And like Niko said, many people voting for features have no idea what they're voting for, which really sounds like a bad situation. So yeah, there is no easy solution to this. But what was jarring to me when I watched this video was the atmosphere of doom and

gloom. I didn't like that at all. You can be constructive and at the same time calm. And my impression of the panel was that Kate Gregory was the most calm and reasonable participant. It's almost like men are too emotional for C++, am I right? I would say people are angry because they have problems. They cannot end these problems. They just cannot figure out how to fix them. And sometimes these problems are so deep in C++, they just give up and just say, OK, I will use another language. But it's another problem.

It's not another language that's so popular as C++. And it adds more angriness as well. I have talked several times with a bunch of newbies for C++, and people who worked with C++ for several years. And almost everyone agreed that it's too hard to study, and it's too many places where you can shoot yourself in the leg. Something is definitely not as well as it should be. The question is how to fix it.

Then Bjarne used to say there was a nice language somewhere as a subset of the. Oh, yes. Yeah, it's called C. Yeah. Oh, yes. Somewhere in C++ there's a smaller, nicer language waiting to get out or something like that. Yeah, it was like the guideline library was supposed to, like, the guidelines were supposed to get towards that. Indeed, there is a video from another conference that came out recently from Bjarne. And I don't know if you have it in your slides, Gleb. And it goes through all of these problems from a more positive perspective.

And it does mention this subset idea, but includes also adding more features. So having it be a subset of a superset and then including the ideas of profiles, which is a very interesting proposal. And it does explain this very well in the video. I don't know, Gleb, do you know what video I'm talking about? I think so. I don't have it in the slides, but I think I've watched it. I'll find it for next time and put it in the show notes. Yeah. So, Victor Tura provides some more optimism.

Fair warning, I think he works on Visual Studio, Visual C++ at Microsoft. But still, he posted a blog post called Why C++ Today? He says he's both C++ is both our legacy and our future. It's a very mature tools ecosystem. Lots of libraries, including the standard library, with valuable additions coming in C++ 23. And if he finishes with this quote, every important piece of software we use today has some C++ in it. Maybe it's all C++. Maybe it has some important components in C++. Maybe its library is natively compiled in C++. Maybe its compiler runtime is written in C++. And he finishes with this quote,

C++ is still the king of programming languages. Long live the king. Well, that sounded to me, yes, perhaps a bit on the over-optimistic side, but still, it's a nice contrast. And the other article of the same vibe is from Shando Dargo blog. Why use C++ in 2022? Posted in November 2022. And yeah, he also says that C++ is everywhere. Granted, in many cases C++ is used because it's legacy, but it's only partially true because it's not as old as, say, COBOL, and also C++ 26. There's still time and I'm optimistic because

otherwise it would be a doom and gloom. Interestingly he says that there is an economic advantage to using C++ because it's very efficient, it's close to the hardware, and programs written in C++ consume less energy and have a smaller carbon footprint, which is now a situation where at the moment in London is 27 degrees, which is not an ideal working temperature. So yeah, drawbacks, obviously. He says, bad press, quote, let's face it, C++ has a bad reputation. Yeah. We need a new marketing department, that is for sure. Yeah. A new working group in the committee. He says, while the language is evolving, it's getting more difficult to learn. True, but also the new features allow writing code that's more concise. Like in his example, what used to be a raw loop today

can be written in a functional way. Instead of doing a full loop, you could use ranges to do the same thing and it would be more expressive and shorter code. Yes, but to do that, you need to know how to write loop and also you need to know how to write expressions and use the sstd library. So you need to study both, otherwise you're not able to to choose what you need. Yes, and he says pretty much the same thing, quote, while this is all fine and dandy, it also means that those who want to write better C++ code have to learn more. Yeah.

Ecosystem, pretty much build system situation in C++ is pretty tragic, and package management, we all know that. Things are getting better slowly. We have more package managers available and they sort of work better and better. But there's still a long way to go and that stops quick adoption of features like modules. We now have C++23, and we still can't use modules in a cross-platform way because build system and compilers don't support them to the required degree. Indeed, if there was one thing I really, really envy from Rust,

it's cargo. They are able to just have a single command that will generate all the directories with all the tests and files already, and it's all included, packet manager, everything. It's amazing. Yes. This article on Dice is called C++ continues to surge up popular languages list. And it's that Tiobe list. So take it with a bucket of salt. Anecdotally, I see some posts where people are returning to C++ after a hiatus or starting to learn modern C++ after having worked with the legacy C++ for a long time.

So yeah, there's lots of learning required, but it's not all bad, I would say. Speaking of compiler development, we have this toot on Mastodon by Sam who says, GCC14 is still in development, but it has a wonderful new feature in its static analyzer switch-f analyzer. It can now draw beautiful unicode diagrams showing exactly how you went out of bounds. Thank you to the wonderful David Malcolm for implementing this. And here is a picture and it's pretty impressive. It reminds me of something that used to be available in Clang, an LLVM where you could run a static analyzer and it would draw a diagram on top of your code with arrows and

explanations on some memory errors, for example. And this, especially given the Unicode pseudo-ASCII graphics in Terminal, including emojis, could be really useful. This is a static analysis tool. It doesn't run like a sanitizer. No, no, this is static analysis in GCC14. You just provide this F-Analyzer switch and it does it. Very nice. I suppose like Clang static analyser or something. Yeah, this does look really nice. Right, next topic. Niall Douglas posted on Reddit. Review of proposed Boost async begins. Quote, it is my great pleasure to announce the beginning of the peer review of proposed Boost

async which is hoped to become the most popular way of programming C++ coroutines in future C++. Like many of you have found, until now there has been no good standard and easy way of writing C++ coroutine code which works easily with multiple third-party codebases and foreign asynchronous design patterns. ASIO's current coroutine support is tightly coupled to ASIO and it rejects foreign awaitables. libunifex, which is senders receivers, is dense to master and non-obvious to make work well with foreign asynchronous design patterns, not helped by a lack of documentation, a problem which also afflicts SteadicSec, which also has a steep and dense learning curve.

CppCoro, this is a library of coroutines written by Lewis Baker, I think, on top of C++20 coroutine support. CppCoro, he continues, is probably currently the best-in-class solution to the space of easy-to-use, fire-and-forget C++ coroutine programming. But it isn't particularly portable and was designed long before

C++ coroutine standardization was completed. So basically, this library, this new library BoostAsync uses BoostAsio as its base executor. I think it will enable more people to use coroutines and asynchronous programming in C++ before senders and receivers are complete. In C++ 26 maybe. The quote continues, likely very common question, how does this compare to senders receivers? Instead execution P2300. Senders receivers are the natural abstraction over C++ coroutines and map also organically onto them. P2300 aims to implement structured, pre-planned rather than ad-hoc concurrency which infers lazy rather than eager awaitables. A lot of the complexity and learning curve in P2300-based code stems from these design

choices plus additional effort to manage the by-default dynamic memory allocations of lazy awaitables. Boost Async is eager-waitable and ad-hoc concurrency-orientated, and doesn't bother with abstracting out C++ coroutines at all, instead choosing C++ coroutines and Boost ASIO as concrete, immutable design choices. It's almost the opposite of P2300 in terms of philosophy, as a result, by vastly reducing the number of potential customization points in exchange for getting users up and running quickly without having to think much about why or how. T2300 will have much more power and flexibility, but if you are happy with C++ coroutines and Boost ASIO and don't need anything more, Boost Async should be hard to beat." End quote.

That's a very interesting development. I honestly, after all the critique that Niall Douglas posted over the years about senders-receivers, I didn't have much hope for him doing anything about it. But this is, in my view, it's a very welcome thing that he started. And yeah, I'm very happy to see it, because you've probably seen some code using senders receivers. It's pretty dense and pretty hard to understand. Maybe it's the unfamiliarity aspect. But I mean, if we have something that's pretty much ready to use, which is based on Boost ASIO, which is currently the gold standard that we have already for networking, I'm all for it. I'm really interested in this and I'm really happy that this exists. I've just been watching Apple's presentations on async programming in Swift and it's so nice and easy.

I mean, if only we had something like that in C++. It's like a no-brainer. Everything works. If you know C Sharp, it's pretty much like async await in C Sharp. Very similar. But sadly, we don't have anything even close to it in C++ and if we have to use boost async for that, so be it. And then we can wait for the proper general solution to everything in the form of senders-receivers. There is a GitHub repository with this code.

It requires C++ 20 and Azure. And this is documentation, which is quite nice. So yeah, happy to see it. Let's see how this progresses. Boost review takes months, I think, so it'll be a while before we have this in Boost. But if you want to experiment with it, there's already a GitHub repository. Right. Next up is an article by Nick Atanasiu called Composing Callables in Modern C++. Quote, Composing callables is a typical and useful functionality one could ask from a programming language. The canonical explanation of composition includes the example function calls h equals f of g of x and equals in parentheses f multiplied by g of x. So a composition of two functions f and g. This means, he says, the effect of calling h is that of calling f

with the result of g of x. Being statically typed, C++ may appear as a nightmare of language to express such mutations. He provides then a possible implementation using the usual template metaprogramming stuff with some C++ 20 additions. He explains this code snippet line by line, and it uses variadic lambdas, variadic function calls, folds, and it sort of processes a list of the supplied invocables using fold expressions. So it checks if there's more than one. So this is like a recursive call at compile time, because everything is constexpr. And one branch of if constexpr checks if there are multiple callables,

and then it sort of composes them by combining a call to itself with the head and then folding over the tail as it's common in functional programming, which template metaprogramming actually is. And the other branch of if constexpr just invokes the single argument, the single callable forwarding arguments to it. And that allows you to write something like this. auto h equals compose, parenthesis open, g, f, z, arbitrary number of callables, and what you get is a combined composed function h, which you can then call with the argument you want. And then he presents a new library solution using ranges in C++20.

And Fairpoint, as it was mentioned, you was mentioned, it's good to know both solutions, but you could almost argue that in order to implement something as he shows with ranges, which is using std views that views transform and composes functions by using transform for each callable and then using pipe to pipe the results of one transform to another. And what you get then, you call ranges single view adapter with the result of the earlier composition and you get a range with a single element which is the result. And you can also sort of enclose this in a helper function using fold expressions. So the final code is very short and concise and you could almost argue that if you know ranges, you don't even need to know how to implement it without ranges. It'd be interesting to see the different assembly generated in various cases.

That's true. Yes. I did notice some some people post that compiler optimizations with ranges code is not as ideal as it could be. But hopefully that will improve with time. And to me, this ranges based solution is much more concise and expressive. I wouldn't be surprised if the ranges-based solution has less bugs but is slightly slower and the metaprogramming one has more bugs but is slightly faster. Yeah, that's probably the case. Right, so the next one quickly is faster, an if-based statement or a ternary operator. And the interviewer expected him to answer that if-else is better

because it's branch prediction friendly, but the ternary operator isn't. And the original poster wasn't convinced that that was true. And interestingly, in the Reddit thread, most people who replied thought that these produced the same code, and you can't just tell which one is more efficient without either looking at the assembly or measuring your performance. And prediction could well depend on the code around that. So I think the consensus is that it depends, but there's no fixed answer to this, which one is more efficient. And most likely, a good optimizing compiler will generate identical code for both. So as far as interview questions go, this is not a good one. Yeah, I think that it's a poorly formulated question. The answer is really a good one. Yeah, I think that it's like a poorly formulated question.

The answer is really it depends. But if you look at the example code at the top of the page, these expressions actually are different because the if code has two assignments, whereas the ternary operator has only one assignment and there could be some type of promotions and essentially could generate different code. So it really, really depends on the compiler and the actual expressions.

Yeah, so maybe if they replied to this question with more questions, like which compiler it is, and what's the code around it, and so on, maybe that would count as a good answer to that. Right. This is on Mastodon. Dario Bassancio posted a picture and the comment is when people say C++ is just C with classes and the picture is an image of a cute cartoon pufferfish labeled C cuddling against a spiking naval mine,

labeled C++. I think the idea is that both have spikes, but one is not the same as the other. Yeah, we also had some sad news. Bram Molenaar passed away. He was the author and main contributor to the Vim editor. He was only 62 and yeah, it's very sad. Yeah, on that sad note, I think that's all for today. And thank you for joining and I'll talk to you soon. Bye. Thank you. Thank you.