C++ Club - Meeting 144

Episode Date: May 21, 2022

https://youtu.be/oPhk0ROzPaQhttps://cppclub.uk/meetings/2022/144/

Welcome to the C++ Club. This is episode 19 for the meeting number 144 that took place on the 24th of February 2022. C++ 23 update. Standard library modules are in. The paper by Bjarne Strostrup, standard library modules std and std compat was unanimously approved for C++23. Hooray! This is the GitHub page for this paper. Luge reviewed and approved it for C++23. Sender's receivers for std execution are out. There was no consensus for sending this paper to Luji for inclusion in C++23.

The GitHub page for the paper has been tagged C++26 instead. 6 votes against and 11 strongly against. Oh my. The comment says, quote, There is sustained strong opposition against including such a large proposal into C++23 at such a late stage. It is also unclear whether we would be able to complete wording review in the limited time we have available. Timing is a major factor in the lack of consensus. The overall design still has strong support.

Vinny Falco posted on Reddit, quote, Sender's receiver's paper is dead in the water for C++23! Three exclamation marks. Personally, I prefer the executor's N-networking solution offered by Networking TS, which is based on ASIO and BoostASIO, over the ad-hoc design of Sender's receiver. End quote. Is he gloating? and Boost.Azure over the ad-hoc design of sender's receiver." Is he gloating?

No. Not Vinny Falco. Redditor Epikar writes, I do think the P2300 design has promise, but C++ standardization isn't where you start designing something like this. You release it as a library, get other people involved, and let it grow and stabilize over a few years. Once it gains momentum, then you can take what you've learned and talk about standardizing it. It's unfortunate that so much time was spent on this proposal at the expense of other stuff."

Facebook has been running libunifex for a while now. This is it on GitHub. It's a unified executors implementation. This is what another redditor says about it. Quote, when I initially started playing with libunifex, I just got stuck. The documentation is incomprehensibly dense, the examples are meaningless, and the code looks like a different programming language. Only after seeing Eric Niebler's CppCon talk last year did I gain enough understanding to actually be able to write some code that compiled and did something remotely related to what I was aiming for.

In doing so, I found that this design really seems to force you to write nasty template code that becomes an utter mess of boilerplate if you don't want to expose all implementation details in your header files. Eric Nible responds, quote, Legit. Time is tight. Documentation is hard. I haven't found a good solution to this problem yet. At least you found my talk useful. I've been meaning to turn it into a series of blog posts which might help somewhat." One redditor angrily addresses the above note about senders and receivers being

designed in the committee. S&R was not started by the committee at all. That's bullshit propaganda from the opponents to this paper. Eric Nieble clarifies, S&R started life within Facebook

as a generic solution for safe, efficient, composable concurrency. It is used in many of Facebook's mobile apps where size and speed matter." He then says, quote, "...those in favour of forwarding for C++23 outnumbered those against by more than 2 to 1. That technically is consensual by the committee's own rule of thumb for such things.

The chairs make the final call though, and they felt that waiting was the better option. I'm disappointed, but I see the vote as a strong endorsement of the direction of P2300. Although it's foolish to make predictions when it comes to WG21, I'll do it anyway. I'm confident that sender's receivers will be in C++26, probably very early in the cycle. End quote. Then the discussion goes into the usual hot topics like API, the committee, what should and should not be in the standard. A separate thread goes into comparison of ASIO and senders-receivers with clearly defined sides and I think there's a consensus that senders-receivers is a better design. Also ASIO is a poor fit for resource constrained platforms while

SNR works on the smallest microcontrollers. There is an interesting example of SNR pipelines being optimized away on Godbolt. A Redditor asks, Can you please provide an example of something the SNR proposal can do, or even is proposed to do that cannot be done in ASIO now, today. Steve Downey replies the one that is brought up repeatedly is heterogeneous operations, ones that move between CPU and GPU, in particular in the face of cancellation. This wasn't a concern for ASIO when it was written.

It's a base concept for S&R. I'll also say that it's straightforward to make lazy become eager, just as it is to make async-bethink. The other way around is a challenging open problem." So the Ascender proposal is now tagged C++26 and I hope it gets there. StudExpected. This paper is in C++23. Quote, we consider expected as a supplement to the optional type, expressing why an expected value isn't contained in the object. End quote.

So, a standard alternative to function return codes is now in the standard. This will end C++ error handling debates once and for all. Stead function ref. This proposal has been adopted to C++23. It's a non-owning equivalent of stead function that is more efficient and optimization friendly. What happened to std hive? A post on Reddit discusses the situation around the std hive proposal which did not make it into sql class 23 despite supposedly being ready. The post starts with the following quote

StatHive is a simple container that is visualized as a chain of blocks storing and erasing elements efficiently and guarantees iterator stability since nothing is moved around. The proposal is literally the most revisioned P paper in C++ history with 19 revisions. The reason for such a high number of revisions can be seen from the fact that in the current state half of the proposal is the appendix that deals with all kinds of questions that luji and sg14 threw at the author. The actual design and wording is fairly small-scaled. The poster continues. The last formal talk on the proposal in a subgroup is way back in Kona

in February 2019 by Lyuji. Around some time in October 2021, Lyuji backlogged and was forced to use all the available telecon and EP space to talk about things that are prioritized for C++23 – ranges, executors, std generator, mdspan. This paper is silently dropped from the schedule and never recovered. And it obviously missed the train. Throughout the whole of 2021 the Steadhive paper is the only paper that is originally scheduled but never really discussed at the end. He then says there is no one to blame in this situation. Committee and groups are doing great jobs and a great salute to

Luji and other subgroups. Everyone makes tremendous efforts to land a lot of proposals on track for C++23, and StatHive is by no means one of the priorities. The author is also doing a great job, constantly producing revisions and answering all the issues in great detail. Yet everyone is doing the right thing, something still went wrong. A perfectly good proposal matured and with plenty of time simply gets ignored and missed the train. Many of us even hesitated to submit our own proposal just because of what happened to P0447. Your heavy investment in your proposal can just be ignored for years.

Don't take me wrong, I will never blame the committee for this. Both the committee and the author are doing the right thing. So what went wrong? The posting concludes, I think solving the problem raised is crucial for maintaining people's interest in writing new proposals or participating in C++ standardization in general. End quote. The thread has some interesting takes on this.

David Goldblatt writes There's sort of a question of what should go in the standard library that Luji has never formalized an answer to. Steadhive seems to be in a sort of situation where nobody, but the author, really cares that much whether or not it gets standardized. So it's easier for the people in the room to take any excuse to not bother with it and focus on something else. So, Steadhive goes through like 20 revisions for mostly minor details. I think the author is sort of misreading the dynamic, as people don't understand the point of this data structure because it's uncommon. I think it's more people understand but are not convinced.

Billy O'Neill writes, quote, The advantage of putting things into std is that they are available everywhere. A corollary of that is that anything that goes into STED must be possible to be made available everywhere. This is part of where the ABI restrictions come from. This is why I personally, not Microsoft, still oppose networking in the standard. Not because I have a problem with the ASIO design, but because any responsible networking needs TLS, and we don't believe we can get TLS that meets standard library's requirements. Given that it's a container, there's no reason std hive can't go into standard library. But anyone who cares about its performance-sensitive nature will be better served by something

not in std without std's very strong ABI compatibility requirements." Redditor solokiller writes, I'd agree with restricting what's in the standard library if the standard actually had some kind of formalized library or package management but it doesn't. With that, the discussion descends into package management, with shoutouts to other languages like Rust, Python, and Zig. Graphic Robot writes, Every time StudHive has been discussed in SG14, the low latency subgroup, it's been

high priority and something that is widely used in that context. Jonathan Muller writes, quote, Luji is still severely backlogged. Quoting the minutes from the most recent admin telecon, Luji continues to meet weekly and has made some good progress, but we still have a huge backlog of papers, some left over from before C++20 was published and many new ones. There is no chance we will review them all for C++23. So even if Luji decides to approve the paper, I would have been surprised if Luji didn't have time to review it.

All the high-priority stuff has a lot of wording that they need to go through. Vinny Falco didn't miss an opportunity to make a snarky comment regarding the time the committee spent on P2300 and was quickly downvoted. There are some more radical ideas in the thread. Redditor Lenkite1 writes, quote, I believe the three-year time gap is too much for C++ standardization. Have a yearly train. That will also increase motivation considerably for paper authors.

To which Steve Downey replies, There is no way to turn the ISO crank faster than 3 years. You get eaten by the overhead. Getting the C++ standard out of ISO would be a very tall order. So to conclude, hopefully stdhive makes it to C++ 26. In the meantime there is PLF colony, which stdhive is based on. February C++ standard committee mailing. This time there's a quite a few papers at version 0. The work on C++ 26 is starting now that C++ 23 reached feature freeze. It'll be great now that we've been told the pandemic is over.

Just kidding. P2536, Distributing C++ module libraries with dependencies JSON files. This paper proposes to include a JSON file describing module dependencies alongside module BMI files when distributing pre-built module libraries. P2544. C++ exceptions are becoming more and more problematic. Yes, that's the title. This paper argues that exceptions are incompatible with modern multi-core systems, provides benchmarks

of various error handling methods for a multi-threaded program that randomly produces errors i.e. an artificial pessimistic case, and proposes several ways of fixing exceptions. Stead expected, boost leaf, Herbsatter's throwing values proposal, or Herbceptions, and fixing traditional exceptions, which requires an ABI break. In the Reddit thread, Billy O'Neill says, quote, The problem described there is generally about how operating systems deal with dynamic libraries and the metadata needed to unwind a stack correctly. Nothing the C++ implementation can do on its own can meaningfully fix that.

End quote. Another poster says, quote, saying that exceptions are slow when you throw them thousands of times per second is completely uninteresting. The community hopefully knows not to do that. If you're using exceptions for heavy-duty input validation,

you're going to have a bad time. Exceptions remain free for the non-throwing case and you should use them appropriately if it makes your code easier to maintain and another reply quote so the paper basically says that handling a gazillion exceptions simultaneously could be slow? Wow, that's a revelation. We have to do something ASAP. P2546.

Debugging support. This paper combines previous separate proposals for std breakpoint and std isdebugger-present and adds std breakpoint and std isdebugger-present and adds std breakpoint-if-debugging. P2547 Language support for customizable functions This paper proposes to add customization points in the form of namespace scope virtual functions which can be pure and can have default implementations quote a customizable function prototype creates a name that identifies an empty object

that can be passed around by a value this object represents the overload set of all overloads of that function and so can be passed to higher-order functions without having to wrap it in a lambda." This is an interesting new language-level alternative to tag-invoke customization point objects that would replace it in senders receivers C++ cheat sheets Hacking C++ has an entire page full of C++ cheat sheets and they look amazing

the diagrams explaining various concepts algorithms and containers are very well done definitely one for for bookmarks or maybe even for bulk downloading of all the cheat sheets in case the website disappears or the internet is down due to a storm, or there is a war but you still need C++. Wow, this suddenly got dark somehow. Swift and C++ interoperability workgroup announcement. We discussed C++ and Swift interoperability manifesto previously.

There is a new development in this area. The creation of a workgroup dedicated to C++ and Swift bidirectional API-level interoperability. Quote, Over the past few years, there has been a huge amount of interest in bidirectional interoperability between Swift and C++. The Swift compiler is now able to import and use some C++ APIs, including C++ standard library types like std string and std vector. To advance the interoperability support between Swift and C++, we are announcing the formation of the Swift and C++ interoperability workgroup

as part of the Swift project. This is very welcome news. There are many tasks for which C++ is better suited, like working with memory or system APIs. And to be able to use C++ in a Swift program, especially with two-way access, will be really helpful. It also shows that no matter how focused Apple is on Swift, they must have realized that C++ isn't going anywhere and there needs to be a way for Swift to use it. Which standard C++ library elements should I avoid? A Redditor asks, quote, I'm aware that due to ABI backward compatibility and historical reasons,

there are parts of standard library that shouldn't be used. I've seen people complaining and warning about regular expressions, unordered containers, since they are apparently horrendously slow. What about the other stuff? What else is advised to be ignored? End quote. The most sensible advice seems to be to avoid nothing and measure performance.

However, many redditors concur that std regex is very slow and should be used. Apparently, boost regex is about 10 times faster and there is also much-anticipated compile-time regular expressions and should be used. Apparently, Boost Regex is about 10 times faster, and there is also much-anticipated compile-time regular expressions by Hanna Dusikova that you can use with C++17 and C++20.

According to a Microsoft STL developer, Stud Regex is bad, and you should forget it exists. Regarding std map versus std unordered map opinions differ. Some say that map is slow and you should use unordered map unless you need ordering. Others point out that unordered map has more requirements for the element type hashing. I like this quote by Mark99. Unordered map is never very slow under any of the possible use cases. A link was posted to a set of benchmarks for the most common hash map implementations which show that

std unordered map is indeed slow compared to other hash maps another Redditor says not to use Iostreams as they are slow and add too much bloat to the binary which is especially important in the embedded space. The FMT library is much faster, has very small code size and is easy to work with. To speed up maths, this redditor says, if you don't rely on it, disable math urno on your compiler the C standard mandates that otherwise single instruction operations like square root return their errors as erno value which

can result in half a page of cleanup instructions for every instructions of for every instruction of actual work. Ereditor says I don't use thread anymore just use Jthread. Remember the proposal to make random usable which didn't make it into C++ 23? Ereditor writes quote random is suboptimal and worth avoiding because all of the generators provided are slow or have poor statistical qualities and it's generally difficult to use correctly. There are also discussions of stdlist vs stdvector, which you can read yourself. I don't know which container to use.

A related article by Chloe Locey on the Belay C++ blog goes into details of container selection given a task and requirements. Quote, as far as containers go in C++, since std vector is well suited for most cases, with the occasional std map when you need key-value association, it's become easy to forget that there are other types of containers. Each container has its strengths and weaknesses." The author presents two matrices illustrating container properties, one for sequence containers and another for associative containers.

She also shows Joe Gibson's data structure selection flowchart. Quote. Vectors are the most understandable structure because it is quite close to the plain old arrays. Most C++ users aren't experts and std vector is the container they know how to use best. We shouldn't make mundane code any more difficult to read and understand. Of course as soon as you have special needs you should use the most appropriate container, but that doesn't happen very often. Chloe reminds us that optimization should not be the first consideration.

Only after you measure the performance you should start thinking of choosing a faster data structure. She provides her own flowchart that works like a preliminary step before referring to Joe Gibson's flowchart for more granular selection her flowchart advises to use std vector and std map by default there is a footnote clarifying use of unordered containers quote unfortunately the presented flowchart lacks any unordered associative containers but you can think of it like this values need to

be ordered if yes map set if no unordered map unordered set there is a short reddit thread discussing this article the first reply is almost always vector regarding maps a redditor says almost never use stdmap if you think you need stdmap you really want stdunorded map I'm looking forward to stdhive in C++26

standard pronunciation a redditor writes quote how do you read a code like this? StdVectorInt? Like is it std colon colon vector int? Most redditors in the discussion don't pronounce colon colon and say simply standard vector of int.

Some go to the trouble of saying STDE vector int. Or even STDE. Four dots without lines in the shape of a square left. Vector unfinished acute triangle facing east. Int unfinished acute triangle facing west. This is a pretty unique take. Quote. The teacher of the first computer science classes I took once gave us vocal sound effects to use for punctuation. Just for fun, we didn't actually say these in class.

I think some of them might have been... Dot. Comma. Puh. Right arrow. Woosh. dot comma right arrow whoosh exclamation mark whooped left parenthesis upward whoosh right parenthesis downward whoosh

there is also this curiosity from PHP if you're not sure how to pronounce Downward. There is also this curiosity from PHP, if you're not sure how to pronounce colon-colon. Apparently, in PHP it's officially called Pamaim Nekudotaim. The name Pamaim Nekudotaim was introduced in the Israeli-developed Zend engine used in PHP 3. Although it has been confusing to many developers who do not speak Hebrew, it is still being used in PHP 7, as in this sample error message. Parse error, syntax error, unexpected t pamaim nekudotaim a redditor replies wait it isn't even spelled correctly to which another responds it's PHP what did you expect

can you please have some Danish keywords in C++ just so that I could hear people try to pronounce them some people pronounce STD as std including Stefan T. Lovewade this could be a good approach if I'm reading out loud it will be std vector of int. If I'm dictating it will be std colon colon vector opening angle bracket int closing angle bracket. Using C++20 modules with Bazel. Apparently Bazel does support modules and this article shows how to set them up using Clang. I'm bookmarking this for future reference. Looking at the build definition file,

it strikes me as pretty verbose and very detailed, with all the compiler flags specified manually. But what if you don't want to spend too much time on that and just use sane defaults? Check out Xmake, which I'm happily using for my toy project. C++ IDE poll. Redditor asked what is your favorite C++ IDE?

Here are the results of the poll. pool. 2100 vs code, 2000 votes visual studio, 1.1000 sea lion, which gets my vote, 830 vim, 797 code blocks and 753 other. Some points from the following discussion. Visual Studio is better than VS Code, but VS Code is free and cross-platform. There is a free Visual Studio Community Edition, but it is also Windows only. And Visual Studio for Mac is a misleading name as it doesn't support C++. Qt Creator is an excellent and free cross-platform IDE even if you don't use Qt. KDevelop is another great free IDE. Emacs absence didn't go unnoticed.

But the reply was, they're asking about favorite IDEs not favorite operating systems people remember Ball and C++ fondly nobody mentions the successor C++ builder probably because it's not very good and is Windows only and very expensive there is a C++ builder community edition if you eligible, and some people even use Eclipse CDT.

I use Visual Studio on Windows and CLion everywhere. This is it for today, and I will leave you with this tweet. In German, the word Verschlimmbessen means to make something worse while repairing it. In English, we call that software development. Thanks for joining me. Until next time. Bye.