C++ Club - Meeting #134

Episode Date: September 5, 2021

http://cppclub.uk

Hi, I'm Gleb from London. I run a C++ club at work. You can find our meeting notes at cppclub.uk. This podcast and the meeting notes contain public information only. This is episode 9 for the meeting number 134 that took place on the 26th of August 2021. The WG21 committee mailing of August 2021 is out. The following papers caught my attention. P1072 basic string resize and overwrite. The ninth version of this proposal has got some fixes and enhancements. This should be a useful feature to make string manipulation more efficient. P1169, static operator parenthesis.

This paper has received some fixes since it's been reviewed and seems to be progressing well. It also has been implemented in the EDG or Edge compiler, which powers Microsoft Visual Studio IntelliSense and does nothing else as far as I know. P1206 – conversions from ranges to containers. This proposal received some review fixes too. To remind you, it adds rangesTo function that can materialize any range as a specific container, and also adds tagged constructors and functions insert and assign for standard containers and string types.

P2093. Formatted output. The eighth revision of the formatted output proposal from the text formatting ninja Viktor Zverovich added lots of poll results for various aspects of the paper. If nothing else, they demonstrate how difficult it is to get a consensus for a new feature in C++. P2370 stack trace from exception. This useful feature becomes off by default because it can increase memory consumption by exceptions. The authors also propose a linker flag that can turn the feature owner off.

P2425, Expression Function Body. This is a new proposal, revision 0. Quote, this paper suggests a way of defining single-expression function bodies that is aimed at solving one of the issues which prevented standardizing the abbreviated lambdas proposal. End quote. C++ lambda syntax is too verbose. It would be so nice to have a shorter syntax for most common cases. Unfortunately the previous attempt failed because of various corner cases and subtle issues. This proposal is an attempt to solve one of those issues, differing semantics with regular

lambdas, meaning that the same function body would return different types depending on whether it was an abbreviated lambda or a normal one. This issue was caused by the way abbreviated lambdas were defined, which meant that reference semantics was the default, as opposed to value semantics in normal lambdas. The paper offers two solutions. First, the minimal expression has reference semantics by default, and the non-minimal expressions has value semantics by default. And second, the minimal expression has value semantics by default with opt-in reference

semantics. In the end, though, the paper just adds a whole lot more corner cases, so I'm not sure now if it's worth it. Maybe the current lambda syntax is actually okay. You don't want to make writing a Lambda in C++ an expert feature. P2428, revision 0, slides BSI issues with P2300. The new sender's receiver's proposal, P2300 or Stead Execution, has been discussed by the Committee. There was a consensus in favour of abandoning the previous Executor's Proposal, P0443, and switching efforts to the new paper.

So, it's another reset. These slides show the issues the British Standard body had with the new executors proposal. I'm sure all of these are valid issues and there are quite a few of them in the slides. But I fear C++ executors won't be executing anything till at least C++ 26 and then we'll have to wait until C++29 for them to work out the kinks and become usable. See coroutines. P2412 revision 0. Minimal module support for the standard library. This paper by Bjarne Stroster wasn't in the mailing as it was released just before it went out. Bjarne urges to adopt basic standard library modules as soon as possible, so that they get in C++23, the main modules being std.

This would simplify adoption of the C++ modules, with more granular standard library modules possibly coming later. Reddit offers this insightful comment. Quote, This seems like a reasonable, well-thought-out proposal that would have real practical benefits to C++ programmers now. As such, I expect it to be rejected in favor of a proposal that will solve all module-related issues forever

which hasn't been written yet, that will never actually happen." End quote. Another deep sigh. Boost 177 released. Highlights include a new C++14 reflection library described by Peter Dimov. Unavoidably macro-based until we have proper reflection in c++ probably in c++ 26 now a new c++ 14 lambda helper library lambda 2 by peter dimov again if you've been watching in frustration the failed proposals for simplifying lambda syntax this one could be for you it adds pseudo variables starting with underscore, like underscore one and underscore two

that signify lambda parameters. You might remember them from the bind function syntaxes. Boost file system version four with lots of changes and new features. Tons of changes and new features in ASIO, thanks to Christopher Kolhoff. These include cancellation support for individual asynchronous operations.

See also the article on Boost.177 by Jens Weller. Vinny Falco posted excitedly on Reddit about the new features in Boost.ASIO.177. Quote, Kolhoff is a C++ design god. End quote. Vinny Falco also replied to another Redditor. Quote, do note that all of these changes are built on a networking TS. In other words, none of the core concepts in networking TS are incompatibly changed to support these features. End quote. And then we have this Redditor saying, only one who just hates it with a burning passion. Whenever a project of mine requires networking,

I end up reaching for ASIO because it's the least worst option we have. And so, when I want to do networking, I first have to wrap ASIO before I can focus on what is it I actually want to do. So that right there is issue number one. ASIO is just too low level to do anything useful with. Issue number two, it is just a giant minefield of lifetime issues. Issue number three, ASIO pretty much requires shared data everywhere to get cleanup even remotely correct. The threat has some explanations and alternatives. Most replies say that ASIO is a low-level foundation that enables other high-level libraries to be built on top of it, like Boost Beast by Vinnie Falco. If you use ASIO, you have to buy into it at the application level.

Redditor Minimonium says, quote, the whole issue of async models is that they are required to be universal. That's why standard executors are so important and why it's so frustrating to see so much ego from P2300. It's understandable that the standardization process sometimes may be hard and frustrating.

But I'd hope that the committee members would refrain from I'll take my toys and go play by myself tantrums. They continue. Initially, the executor's proposal was based on the ASIO design. It has more than a decade of user experience, dozens of thousands of users, and achieved grand success in its field. But for standardization, it's important that an executor model that would be picked would

satisfy the requirements of all members. And the ASIO model is more optimized around the I-O part, hence the name. The issue, though, is that for the parallel processing domain, the trade-offs are not optimal. So a part of the committee designed a new model called senders-receivers, which allows to queue continuations in a lightweight manner, which unfortunately prevents the use of coroutines. All is great, we've got the unified executors paper, which seemed to be a consensus among the experts on how C++ must proceed.

But sender-receiver folks were unsatisfied with the presence of ASIO facilities. And failing to convince people who need ASIO facilities that they don't actually need it, they decided to make a paper that would just scrap everything instead of proceeding with the compromise. Unfortunately, greenfield designs tend to confuse people, making them believe that now they know how to solve everything for sure. Due to the lack of expertise and the refusal to admit that all people make mistakes, they forgot that requirements for AIO, async operations and parallel processing are not quite compatible and composable. And then they finish with this. The P0443 was indeed a

collaboration. The P2300, on the other hand, is an unconditional departure, which is problematic with respect to disagreements from other members, end quote. Wow, what a mess. This looks like a classic case of great is the enemy of good. But back to the main topic. Niall Douglas pitched in. Quote, I gotta be honest, I think you haven't spent enough time studying ASIO to use it correctly. Sure, ASIO is a legacy design with a lot of backwards compatibility craft. Rather like C++ itself. So same as with C++, for new code, ignore the 80% of the stuff you don't need. Use the 20% which makes it for clean, highly maintainable, efficient code.

End quote. except for clean, highly maintainable, efficient code." Another library mentioned in the thread for its much more friendly interface is Poco. And of course we have this, quote, I'm not trolling. Use Rust, the grass really is greener. You are trolling though. When to use shared ptr for lifetime management in ASIO? Prompted by the Reddit thread we just discussed, Vinny Falco asks when you should use shared

ptr for lifetime management in ASIO, in async programming in general. Except it's not really a question, as he says at the end, quote, there is no reason to be scared of shared pointers or avoid them just because of some anecdotal evidence that someone in the past sitting next to you in a cubicle wasn't able to use them correctly. Shared pointers make sense when ownership of an object is shared by multiple entities. This is typically the case for network programs. End quote. However, others disagree. Redditor xBigBoss says, quote, Technically, ASIO programs can be structured

so as to avoid all forms of ownership. If one designs their programs to have a pool of sockets that lives longer than the threads that call IOContext run function, then no form of ownership is required. Instead, connection objects simply borrow the sockets and use them for their own purposes, returning them back to the pool when the connection ends. End quote.

Niall Douglas is of the same opinion. Quote. This really of the same opinion. Quote. This really is the right answer. I wish ASIO tutorials taught this instead of the anti-patents which seem to confuse people. In the past decade of writing ASIO-based code, I can't think of ones that I have used shared better. Just structure your ASIO-based program to never encounter lifetime issues. Problem solved.

End quote. Note to self. Beware of answers that start with the word just. Chris Kolhoff started a series of videos, accompanied by a GitHub repository, called Talking Async. From the announcement, Reddit post, quote, Game-changing new ASIO features, C++20 coroutines, and live coding, end quote. The first video is called, why C++20 is the awesomest language for network programming. The second video is discussing cancellation in depth. This is a very welcome series from the author of ASIO himself.

Some compiler news now. Intel C C++ compilers complete adoption of LLVM. Intel's OneAPI C++ compiler now uses LLVM Clang frontend, delivering faster compile times, better optimizations, enhanced standard support, and support for GPU and FPGA offloading. The old or classic CEC++ compilers included in Intel Parallel Studio product are now legacy technology and won't be updated. For those users who can upgrade to the new compilers, this will be a welcome change.

Gone will be the days of finding cumbersome workarounds for ICC internal compiler errors and C++ standards non-compliance. Visual Studio 2022 previews 2 and 3. Visual Studio preview 2 has been announced a while ago now on the Visual Studio blog. This build comes with the new version of the build tools, version 1.43, which is still binary compatible with the previous versions back to 1.40, which was in Visual Studio 2015. It also has CMake integration

for targeting Windows subsystem for Linux 2. New productivity features for C++ developers include hot reload, when you can apply changes to a running application. It's like the old Edit and Continue feature, except in many cases you don't have to stop the application to apply the changes. On the Reddit thread, Stefan T. Lovewwaite posted the STL changelog. Microsoft are beginning to merge C++23 features. Previewed 3.1 was released on the 16th of August, and the new features for C++ programmers are

better CMake support, improved IntelliSense, own-by-default C++ code linter, and improved hot reload feature. That's it for today, and I'll leave you with this tweet. Viktor Zvirovich translated a tweet from Russian. Daddy, I think you love C++ and metaprogramming more than me. Don't be silly, Alex Andreska. If you didn't get the joke, check out Andrei Alex Andreescu and his Wikipedia page.

That's it. Take care and I'll talk to you next week. Bye.