C++ Club - Meeting #127

Episode Date: April 22, 2021

For show notes, visit https://glebd.github.io/cppclub/CppClubUK-127-20210422.html

Hello, my name is Gleb. I live in London and I run a C++ study group at work. In our weekly meetings, I talk about C++ news and anything related to C++. The meetings have been going on for a while and have their own numbering. You can find the notes at cppclub.uk. This podcast and the meeting notes contain public information only. This is podcast episode number two for the meeting number 127 that happened on the 22nd of April 2021. Bazel is Google's very scalable and fast build system. It's cross-platform.

It supports C++ and other languages. Bazel only rebuilds what is necessary. With advanced local and distributed caching, optimized dependency analysis, and parallel execution, you get fast and incremental builds. Visual Studio 2022 announced. Microsoft announced the next version of Visual Studio 2022 on their blog. The first public preview will be released this summer and the main highlights are Visual Studio is now 64-bit yay reddit seems to be excited about it as well presumably they're gonna migrate all their internal servers and such to 64-bit to for them to be able to be hosted in

the new ide or we discussed a blog post by the authors of visual Assist X, which is a plugin to Microsoft Visual Studio that enhances IntelliSense and provides other nice features for C++ developers. And they were explaining what kinds of hoops they had to jump through to make their plugin work while being hosted by a 32-bit IDE. It was not trivial what they had to do, because they needed so much more memory to be responsive and to be able to load big projects. So I guess at least they would be glad to see that.

One of their showcase videos in the blog post is Visual Studio 2022 loading a huge project with 300 thousand files. So yeah. There will also be a refreshed user interface, some new icons, yay! By the way, as you can see, this save icon is still a floppy disk. I mean, the new developers just starting their careers probably don't even know what that means. It's a fossil. Another new thing is a new coding font. You might have heard about it, it's available outside Visual Studio and you can download and use it. It's very readable, it's an acquired taste, the

shapes are a bit unusual and there also are no italics, which in Visual Studio I guess it's not a big deal, but it's a very nice font. There is an open issue on GitHub where the development of this font happens to provide italic version. It's a long-standing issue, and hopefully they will address it at some point. There's also support for new C++20 features, and interestingly, they are keeping its runtime backwards compatible, so that migrating to it would be easier for big companies, I guess. Some redditors are not happy about it, like this one writes I'm rather worried about ancient bugs that are not going to be fixed at least until 2025 now because of this. Interestingly, there is a reply to it from none other than STL, Stefan T. Loverway from Microsoft, who says, we used to break ABI every

major release. It was awesome for development. I was able to fix so many bugs. Lots of customers had trouble keeping up though, which led to them sticking to really old VS releases like VS 2010 for years and years helping nobody. Keeping ABI compatibility in the 15.17.19.22 release series makes development harder but has allowed customers to continuously upgrade, which is an improvement. I hope that when we finally have time to do vNext, we can establish customer expectations for long but not infinite periods of ABI stability, followed by periodic migrations, as we'll always be learning better implementation techniques and

we'll need ABI breaks to establish a solid foundation for the future. From my own experience, the binary compatibility certainly makes life much easier. Other features include integrated support for Windows subsystem for Linux, CMake and plain Linux. There are some remote debugging features available in Visual Studio 2019 already, but this presumably will be even better. Artificial intelligence, machine learning enhanced, IntelliSense. Just recently, in one of the updates to 2019, they've made it possible for the ML-based IntelliSense to learn on your own code base, while previously it was only learning what was available in the provided supplied libraries, like standard library.

So now IntelliSense should be even more intelligent, hopefully. And also built-in support for Git andub. So that's overall very good news. The preview version should be available this summer. Next we have all C++20 core language features with examples. Alexander Kaval wrote an article describing all C++20 features with examples. He says, I wanted to learn about new C++20 language features and to have a brief summary for all of them on a single page. So I decided to read all proposals and create this cheat sheet that explains and demonstrates each feature. It looks like an excellent overview, a brief summary of what's new in C++20, and the examples seem like a very good idea. I'm definitely adding this at the top of my reading list. Or stack even.

The reddit thread about it has a few useful links, like a similar list of features in C++17 with Tony tables. Tony tables are short before and after code snippets invented by Tony Van Aert, the author of this, hence the name. I've noticed that more and more C++ standard proposals include Tony tables for their proposed features, which is a nice, almost unspoken standard thing to do. Next, we have C++20 range adapters and range factories. Barry Revzin writes, ranges in C++20 introduces with it a bunch of range adapters, basically algorithms that take one or more ranges and return a new adapted range, and range factories, algorithms that return a range but without a range as input.

All of these algorithms have several important properties, and I found that it's a bit difficult to actually determine what those properties are just by looking at the standard, so I'm hoping to make this post serve as that reference. Another useful reference type post. He proceeds with listing range types and their properties, which include range reference type, return by operator star, and traversal category, input, forward, bidirectional, Random Axis and Contiguous. He also explains the following range types. Common, when beginR and endR with R for a range return the same type starting with C++20, the sentinel type, that what is returned by end can be different, of different type. Sized, when the range has bigger

of one constant speed member function size. Const iterable, can it be iterated with a const object of the range type? It's not the case for all C++20 ranges. And lastly, borrowed. A borrowed range guarantees that an iterator into a destroyed range does not dangle. I wonder if borrowed is an official term. I think it's more of a Rustian term, but I guess it works here. B Revzin then documents range factories. Empty view, single, IOTA, Istream view and range adapters. Filter, transform, take, take while, drop, drop while, join, split, common, reverse and elements, keys and values. For each of those he describes what this is and provides a code example. So yeah, another reference to be bookmarked. Next we have a Redditor writing, I'm a third

year undergrad student and I just landed a position at a company as a C++ developer. I have been using C++ for a while for academic and personal projects, but I'm wondering if there are certain things I should know about the industry standard in programming that I may be unprepared for. Any pointers you would like to give to someone starting out. Some advice from the thread includes these pearls. Well, to be honest, most of them are quite good, but some of them are amusing, like these two. Write self-documenting code. Too many C++ programmers are scared to type more than one letter variables. The next one. Self-documenting code does not exist. Comment your code. Learn to properly touch type. I admit that I can't properly touch type, as do many other commenters.

Write tests, but don't create a Google mock straightjacket. I didn't even know that thing existed. Apparently what it is is where the codebase takes every or almost every function and describes all of the paths that function can take in google mock. That sounds horrible. I've seen it where the test says things like a will be called twice, b will return this value, c will be called thrice. It sounds like a nightmare supporting this codebase like that. I can imagine something like that being done in NASA for a Mars rover or for some medical piece of medical equipment. Other advice includes identify the people you should listen to. That's in my opinion a very useful one.

Whitespace is free. This is not the 70s. Use it. Keep the coding style of the file you're in. Don't C++ just for the sake of it. Scripting is your friend in many tooling areas. That's an interesting use of C++ as a verb. Must adopt.

Read Effective C++ by Scott Myers always be looking at ways to speed up the build this is so true use Clang format and Clang tidy use sanitizers develop relationships with both developers and business domain experts at work study upon templates learn the standard library move semantics rvo shared pointers if you use const everywhere it makes code a lot easier to think about build small learning projects to reinforce your knowledge and the last one there will never be a time in your career when you are done learning.

In this field, you are forever a student. I like that one. Next, we have an article called Writing interfaces stay true in Booleans. Radek Witt writes, when faced with passing multiple options as arguments to functions, C++ programmers will use enum class without much hesitation. Since C++11, it feels like we have moved away from magic numbers and magic string values, and in most cases it's for the best. There seems to be one exception, when we only have two options to choose from.

Here I will try to convince you to stop overusing bools that don't convey true-false or yes-and-no. He then comes up with the following advice. If you read out the function call with its arguments, bool arguments and return values must be able to be substituted with true-false or yes-no. The example he gives is showWindow, when Boolean is not actually Boolean, but a way to choose between some other options. That's not good. If you had a function called, for example, setDone, Boolean done, then if you call it foo setDone too,

it's obvious what that means. But if you have a foo set done true it's obvious what that means but if you have a window open mode foreground and background and one of them is true and another false and you say show window true it's not obvious what that means from my own experience I can add that combining Boolean parameters with default values is a recipe for disaster due to implicit conversions of erroneously placed arguments to Booleans. that API with an additional parameter being a pointer or something and it

obviously converted to true and was causing all kinds of havoc. The reddit thread suggests some more alternatives like bitmasks and builder pattern. This one says I like making builder options class for cases like this, so that you can call makeT with some default L gray and then dot with milk and dot with leaveTBagIn and stuff like that. An alternative would be to have a struct with the fields that you want to initialize, and then have it as a parameter for your function. And that would give you something resembling named parameters that are not available in C++, but you can sort of mimic them. I think something happened maybe in C++17 that made it easier to use or fixed some issue, maybe with aggregate initialization or something. Of course, proper named arguments could also help

here. There is a proposal to that extent, which is called self-explanatory function arguments by someone from CERN. Basically it's a feature of the language that is ignored by the compiler. Those sort of labels will be totally ignored by the compiler so no new backend, anything is required, but it would provide some clarity in calls like this. So this proposal specifically says, please don't assume that you know what this paper is about, unless you've read the other paper. Several people have invested time in discussing the feature and make it reasonable. Basically, he says, I'm almost certain you haven't seen this before.

And he suggests to allow the naming of arguments in regular index-based function calls, but ignore them from the standards point of view. So that would not affect ABI in any way. Speaking of other languages. MetaLang99, full-blown pre-processor meta-programming for PoC. What she needs is more macros, said nobody ever, except this guy. He writes, MetaLang99 is a functional language aimed at full-blown C99 preprocessor metaprogramming.

It features a wide range of concepts, including algebraic data types, control flow operators, collections, recursion, and autocurrying to develop both small and complex metaprograms painlessly. The most amusing word in this quote is obviously painlessly. I've only included this for the horror value of it. There's nice documentation. The Metalang99 standard library. Basically everything is macros. There's github repository with an appropriate quote from Darth Sidious, a Star Wars character, a bad guy. The dark side of the Force is a pathway to many abilities, some considered to be unnatural. But wait, that's not all. There is also DataType99 implemented using the above library.

It's safe, intuitive sum types with exhaustive pattern matching and compile time introspection facilities. It requires C99 or C++11 and a lot of macros. This is macro level wizardry level 80. Enough horrors. Next is a modern C++ result type based on Swift Rust. Well, when I say enough horrors. A redditor writes, hey everyone, I created a C++ result monad type with functional functionalities and behaviors much like Swift or Rust equivalent result type. It's header only, C++ 11 MIT license, zero overhead, supports constexpr, optimizes very well. There's a GitHub repository and a tutorial. He says initially the library was based on this std expected proposal

but it grew over time. The main differences from std expected are support for monadic operations, support for reference result types, the result type is marked no discard to make sure the result is not ignored and an arguably better naming with expected you have to expect unexpected and result name is less confusing it's by vicente botet from nokia and jf bastian from apple i think he's no longer at Apple, by the way. He's doing something else. The Reddit thread also mentioned libraries like upsell status or. The properties of this is it's not generic over error type. It only uses the upsell error type or status code or something. And it doesn't have monadic operations.

The other very well known is is Boost Outcome by Niall Douglas. It's more complex, has more customization points. It's very well reviewed and is being constantly supported. Niall Douglas has these pages. This outcome documents differences with the proposed std expected. And also, why doesn't outcome duplicate std expected design? So all these motivations are there.

It's a pretty big library. It can be used with or without exceptions and supports various features. I especially liked the comment in the Reddit thread by Dean Roddy. The vast majority of code doesn't care what failed. It wants to just clean and pass the error upstream with minimal hassles. Exceptions plus RAII do that perfectly. Manual error handling is never as clean, no matter how much syntactical sugar you pour

on it. In actual fact, very very little code in a system should end up actually handling errors in any specific way, because generally only the highest level code understands the context and consequences of a failure. And exceptions also work very well for that. As I play around with Rust, I spend an inordinate amount of time dealing with error-return-related silliness in code that doesn't care in the slightest what happened. Judging by the reply thread, people disagreeing with this comment usually come from embedded

background where exceptions are often prohibited. by the reply thread, people disagreeing with this comment usually come from embedded background, where exceptions are often prohibited. Boost version 1.76 was released. The release page has all the details with all the updated libraries. And that's all I shall say about that. Boost is a great set of libraries. Use it, but be careful, as it can be quite a heavyweight dependency. That wasn't a quote. Right, I think that's all for today. And I'll leave you with this tweet by Manisha. She overheard,

Changing random stuff until your program works is bad coding practice. But if you do it fast enough, it's machine learning. And with that, thank you for coming. And I'll hopefully talk to you next week. Bye.