C++ Club - Meeting #132

Episode Date: July 6, 2021

http://cppclub.uk

Hi, I'm Gleb from London. I run a C++ club at work, where we discuss C++ programming news and related articles. You can find our meeting notes at cppclub.uk. This podcast and meeting notes contain public information only. This is episode 7 for the meeting number 132 that took place on the 24th of June 2021. First, we have TRIP report Summer 2021 ISO C++ Standards Meeting, virtual. Herb Sutter writes, On Monday, the ISO C++ Committee held its third full committee plenary meeting of the pandemic and adopted a few more features in the improvements for draft C++23. The following proposals were accepted into C++23.

P1938. If-const-eval by Barry Revzin, Richard Smith, Andrew Sutton and David V der Woorde. In C++17, we had if constexpr. In C++20 standard library, we got isConstantEvaluated. Turns out, if you want to branch on whether or not a particular expression is constant evaluated, as opposed to runtime evaluated, for example, if you want to have both compile time and runtime branches in a constexpr function, you can't just combine if constexpr and isConstantEvaluated, as it will always evaluate a true. With if consteval, you don't even have a condition,

just curly braces for when it's constant evaluated. P1401. Narrowing Contextual Conversions to Boole by Andrzej Grzemenski. This proposal enables testing integers as Booleans in static cast and if-constexper without having to cast the result to bool first, or test against zero. P1132, Outputter, a scalable output pointer abstraction by Jeanne-Huidh Minid, Todor Boyukliev, and Isabella Muerti. This proposal adds outputter and in-outputter abstractions to help with potential ownership transfer when passing pointers to functions that have a T star star parameter like C APIs found in some operating systems P1659 starts with and ends with by Christopher DiBella.

This generalizes these function templates for ranges starts with and ranges ends with. P21.66 Prohibit basic string and basic string view construction from Nolpater by Yuri Chernyshov. This improves the situation with construction of string and string view from NullPotter, which is an undefined behavior, by adding a compile check for when these are explicitly constructed from NullPotter. In other news,

some progress happened with ConcurrentCTS, which gained support for HazardPointers and ReadCopy Copy Update RCU. Herb Sutter says, The next tentatively planned ISO C++ face-to-face meeting is February 2022 in Portland, Oregon, USA. Per our C++23 schedule, this is the feature-freeze deadline for design approving new features targeting the C++23 standard, whether the meeting is physical or virtual. Next we have Visual Studio 2022 Preview 1.

Announced on Microsoft Visual Studio blog, the first preview of the next Visual Studio release is available for download. Its main purpose is to test and tune the new 64-bit Visual Studio platform. The preview can be installed side-by-side with older versionsbit Visual Studio platform. The preview can be installed side by side with older versions of Visual Studio. The Reddit crowd is excited. Not all developers are lucky to be using a recent version of Visual Studio at work. A Redditor says, quote, We currently use Visual Studio 2013 in work and my manager is planning on upgrading to 2022 when it's out. How much better of an experience I'm about to have. To which the first reply is, I'm so sorry.

There will be no ABI break this time, but Stefan T. Lauerwaid says this about ABI. Quote, It's a limited form of compatibility, from VS 2015 onwards, that allows application developers to upgrade their toolset even when they rely on separately compiled third-party libraries that were built with an earlier toolset. Note that only VS 2015, 17, 19 and 22 are binary compatible. VS 2013 and earlier were from the break ABI every major version days, which were glorious for STL maintainers. I remember how awesome it was and horrible for many customers who had extreme difficulty keeping up with the churn. I'm continually advocating for the vNext ABI breaking project to happen, but the stars haven't aligned yet.

End quote. This version does not contain the new toolchain, which is expected in the next preview. An amusing snippet from the thread. Someone asks how old STL is, saying, quote, you have looked 20 since 2003. I was surprised to see you in an MSDN video from 2013 looking the same.

End quote. And STL replies, I am eternal. Probably because I don't spend a lot of time in the sun, when pretending to be a human I claim to be in my late thirties, among the eldest of the millennials. Next we have a piece of news. Dave Abrahams joins Sean Parent at Adobe.

Dave Abrahams tweeted, Psyched to be joining Sean Parent at Adobe, where we'll reboot the software technology lab. Sean's contributions to software and the art of the programming are legendary, the source of many of my good ideas. I can't think of a better way to empower programmers. Hashtag gonna be awesome. Dave was a C++ programmer and participated in the committee work before he went to work on Swift at Apple.

Now that he's at Adobe, a C++ shop, does that mean he's back in the C++ world? Time will tell. Next, what is memory safety? Or we should all abandon C++? I read an article called What is memory safety and why does it matter? And to say it's biased would be an understatement of the week. But then it was written by the Internet Security Research Group, so they must have some data

to back it up. Quote. Memory-safe languages include Rust, Go, C Sharp, Java, Swift, Python, and JavaScript. Languages that are not memory-safe include C, C++, and Assembly. End quote. The author focuses on two types of memory bugs. Out-of-bounds reads and writes, and use-after-free. After presenting some stats on vulnerabilities and exploits, they come up with this pearl. Quote.

These vulnerabilities and exploits, and many others, are made possible because C and C++ are not memory safe. Organizations which write large amounts of C and C++ inevitably produce large numbers of vulnerabilities that can be directly attributed to a lack of memory safety. These vulnerabilities are exploited to the peril of hospitals, human rights dissidents, and health policy experts. Using C and C++ is bad for society, bad for your reputation, and it's bad for your customers. End quote. That's not all. Using C++ apparently also impacts performance negatively. Because nowadays performance needs multithreading, and it's hard to do in C++, as Mozilla's example shows us. They couldn't get it right, and so they rewrote everything in Rust. Oh, did I mention the author really likes Rust? Towards the end, they acknowledge that not all C++ programs are unsafe.

Quote. Some practices which can lower the risk of using an unsafe language are using some modern C++ idioms, which can help produce more safe and reliable code, using fuzzers and sanitizers to help find bugs before they make it into production, using exploit mitigations

to help increase the difficulty of exploiting vulnerabilities, privilege separation so that even when a vulnerability is exploited, the blast radius is smaller, end quote. They finish with this, quote, we look forward to a time when choosing to use an unsafe language is considered as negligent as not having multi-factor authentication or not encrypting data in transit, end quote.

I had a link to the Reddit thread discussing this article, but I can't find it anymore. The first comment was along the lines of It looks like Rust programmers cannot praise Rust without piling on C++98. This article certainly reads like a sales pitch. Rust is a fine language, but C++ isn't going anywhere anytime soon. This article certainly reads like a sales pitch. Rust is a fine language, but C++ isn't going anywhere anytime soon, and it's not a good look for Rust fans. Next we have format in Visual Studio 2019 version 16.10.

A new post has appeared on the Microsoft Visual Studio blog telling us about the new text formatting facility in C++20 that is available in Visual Studio 16.10 or later, when using the switch std://c++latest. It is based on the libfmt library and has the following major differences. Named arguments are not supported. None of the miscellaneous formatting functions like format.print or format.printf are supported.

Format strings are not checked at compile time. And there is no support for automatically formatting types with a stream out operator. The Reddit thread has many positive comments. One insight is that if your code base already uses libfmt, there's no real rush to migrate to std format as it's a subset of libfmt and requires C++20. Next, why we need build systems. Martin Bond wrote a long essay on build systems and why we need them.

The article is of general interest, but has some details targeted at embedded developers. It's a beginning of a series of articles focused on CMake. The author says the most popular build systems for C++ are CMake and Mison, but at the same time he's worried that CMake seems to be a major pain point for C++ developers. Martin Bond explores such topics as source code organization, source file dependencies, compilation options, with a focus on GCC. He talks about include file locations and which flavor to use when system include syntax with angle brackets versus user include syntax with double quotes.

He warns against using relative paths outside the current file location in user include statement, as this leads to hard-to-track dependencies and unnecessary coupling between project components. He touches on code generation options, preprocessor directives, built-in macros like underscore underscore C++. He finishes by discussing build settings, post-build processing, especially important for embedded programming, and limitations of a build system. From myself I can add that in MSVC the macro underscore underscore C++ is broken

and doesn't report the correct standard version used unless you use Visual Studio 2017 version 15.7 or later and specify the flag ZC colon underscore underscore C++. Otherwise, you get the value 199711L, which corresponds to C++98. This is a very thorough and useful article, and this series looks very promising. The top- Reddit comment summarizes build systems. We need them and love them and hate them. Next we have Black Hole from Interstellar. In the sci-fi movie Interstellar we see a black hole in all its glory and turns out it's scientifically correct. It was no big surprise to learn that the sequence was rendered using simulation software written in C++. The tweet from Massimo says,

the black hole from Interstellar was made possible by 40,000 lines of C++ code, by the implementation of Einstein's equations, rendered on a 32,000 core render farm at about 20 core hours per frame, and the final clip was 800 terabytes. The show notes contain a link to the paper called Gravitational Lensing by Spinning Black Holes in Astrophysics and in the movie Interstellar, which describes the process. From the abstract, quote, Interstellar is the first Hollywood movie to attempt depicting a

black hole as it would actually be seen by somebody nearby. For this, our team at Double Negative Visual Effects, in collaboration with physicist Kip Thorne, developed a code called DNGR, Double Negative Gravitational Renderer, to solve the equations for ray bundle light beam propagation through the curved spacetime of a spinning black hole, and to render IMAX-quality rapidly changing images. End quote.

An article in Wired magazine titled Wrinkles in Space-Time, the Warped Astrophysics of Interstellar has more details. Quote Filmmakers often use a technique called ray tracing to render light and reflections

in images. But ray tracing software makes the generally reasonable assumption that light is travelling along straight paths, says Eugenie von Tunzelmann, a CG supervisor at Double Negative. This was a whole other kind of physics. We had to write a completely new renderer, she says. Next, SIMD vector classes for C++. VC is a library of portable, zero-overhead C++ types for explicitly data-parallel programming. Quote,

Current C++ compilers can do automatic transformation of scalar codes to SIMD instructions, auto-vectorization. However, the compiler must reconstruct an intrinsic property of the algorithm that was lost when the developer wrote a purely scalar implementation in C++. Consequently, C++ compilers cannot vectorize any given code to its most efficient data parallel variant. Especially larger data parallel loops, spanning over multiple functions or even translation units, will often not be transformed into efficient SIMD code. The VC library provides the missing link.

Its types enable explicitly stating data parallel operations on multiple values. The parallelism is therefore added via the type system." Imagine an example using the built-in float type. Using vec3d equals st second is also vec3d. The function finds the ScalarProduct of those two arrays and returns it. With the VC library this doesn't look much different. The first would be a using statement using vce float v, which is the VCE float type. And then the next using statement would look like this using vec3d equals std ray of float

underscore v of the size 3. Nothing else changes, but it will automatically scale to 1, 4, 8, 16, etc. scalar products calculated in parallel, depending on the target hardware's capabilities. The library is cross-platform and comes under BSD3-CLOSE license. The note at the top says, quote, You may be interested in switching to std simd. GCC 11 includes an experimental version of std simd as part of the lib std c++, which also works with Clang. Features present in vc 1.4 and not present in std simd will eventually turn into vc 2.0, which then will depend on std simd will eventually turn into vc 2.0,

which then will depend on std simd. If we look at the std simd project, or std experimental simd, it implements a similar concept of portable, zero-overhead C++ types for explicitly data-parallel programming. Currently, it only supports GCC9. Using std experimental simd, the above code example would look very similar, except the first using statement would say using std experimental native underscore simd, and the next using statement would be using vec3d equals std array of native underscore simd of float of the size 3. Nothing else changes,

except the return type of the function will also be native simd of float, and the effect would be the same as with the VC library we saw above. It's encouraging to see how C++ makes it simple to use the new advanced programming features like data parallel programming. Next, C++ for

functional programmers? I watched this talk by Harald Ahitz at Funkprog Sweden. There are slides available for your reference, linked from the show notes, and there is also the corresponding Reddit thread. Right at the beginning, Harald says that he likes to talk about C++, and that C++ evokes many reactions, not all of them rational. That sounds familiar.

Then we see a brief history of C++ from 1982 to the current C++20 standard. Harald emphasizes the fact that C++ is a multi-paradigm language. He then presents some examples of common functional programming operations and idioms in C++. Filter using stdcopyif algorithm. A lambda that checks the condition and stdbackinserter to put the filtered items in another container. Map using stdtransform with a transformation lambda and stdbackinserter again. Reduce using std accumulate and std reduce algorithms. The latter can perform the operation in parallel. Transform and reduce using std transform reduce and two lambdas, one for reduce and the other

for transform. This one also takes execution policy, which can be std execution par for easy parallelization. Harold reminds us that the naming is different in C++. There is a handy algorithm selection chart by Connor Hextra that can help here. The observations from code samples for all of the above were that there were no row loops, no new or delete, no pointers, and memory was managed automatically.

Then a question was raised, how other functional concepts map to C++, namely high-order functions, immutability, recursion, function purity, and referential transparency. High-order functions, immutability, recursion, function purity, and referential transparency. High-order functions. Aside from lambdas, there are third-party libraries available, like lift by bionfala, which has a number of time-saving functions for combining other functions, like lift if-then-else that takes three functions condition true branch and false branch and returns a combined function that can be passed to an algorithm immutability const in c++ is not

exactly the same says harold in c++ we have value sem, mutable by default and copy by default, where assignment creates a copy and so do function value arguments. There's a library of persistent and immutable data structures called IMA by Juanpe Bolivar. Recursion. Tail call optimization is not part of the standard and is compiler dependent, so not guaranteed, like in many functional programming languages. But you can use loops and algorithms instead. Pure functions and referential transparency.

GCC has attribute pure and attribute const, which work in C, but rely on the developer to guarantee this behavior. In C++, we have constexpr, which makes the compiler check that the function has no side effects. Pointers and resources. Harold tells his audience of functional programmers that pointers are like a maybe type, pointing to a resource. On resource management, Harold says, quote, scope is king, end quote. That was easier to say than RAII, which presented some difficulty later, so Harold quipped that C++ doesn't have great marketing. He then says, quote, for the objects on the stack, the closing brace is the garbage collector. There's no magic.

End quote. He mentions smart pointers too and reminds that in today's C++ there's no new or delete. He says pointers are nothing to fear. Harold mentions C++ features like ranges, which are better composable, can be lazy and hide details like iterators.

In conclusion, as Harold says to his audience, now that you want to write C++, how to proceed? He lists some books. A Tour of C++, second edition by Bjarne Storstrup. From Mathematics to Generic Programming by Aleksandr Stepanov and Daniel Rose, Elements of Programming by Aleksandr Stepanov and Paul McJones, and Functional Programming in C++ by Ivan Cukic. A final quick note from me. This in-person meetup took place in Sweden in September 2020 at the height of the coronavirus

pandemic in a closed room presumably full of people. And those who were on camera weren't wearing masks. Videos like this are kind of scary to watch. Finally for today, a quote for your code review needs. This is a quote from Reddit that you can use in your code reviews. The quote is by Anonymous Developer, and it says, eh, good enough. And with that, thanks for listening, and I'll talk to you sometime next week. Goodbye.