C++ Club - Meeting 143

Episode Date: May 11, 2022

https://cppclub.uk/meetings/2022/143/

Hello and welcome to the C++ Club. This is meeting 143 that took place on the 3rd of February 2022. First we have a thread on Reddit. Why do you like C++? Some of the replies that I liked were, quote, I like it because it does what I ask it to do, and also because it does not do things that I didn't ask it to do. Philosophy. Programmers should be free to pick their own programming style, and that style should be fully supported by C++. I like it because it makes you say WTF why at compile time rather than runtime. I don't like C++ except for a singular reason. My employer pays me well for writing C++.

The January ISO C++ mailing is available. Let's look at some papers. The first paper we'll look at is PE2000, revision 3, the direction for ISO C++, by Howard Hinnant, Roger Oh, Bjarne Strostrup, David van der Woerde, and Michael Wong. The latest update to this paper moves goalposts for C++23 and C++26, admitting that reflection and pattern matching are now targeted for C++26. Contracts look optimistic for C++26 too, but you know how it is with contracts, so... Request for re-inclusion of stdhive proposal in C++23.

Quote This is a brief rebuttal to the removal of StutHive from the C++23 agenda and a request for its reinstatement after discussion within SG14. In the view of the SG14 committee, this paper has had significant investigation, insight and input over the years from both SG14 and LUGI members and can be considered mature, in the sense that the broad strokes will not change. End quote. This paper lists issues raised during LUGI discussion and addresses them.

There is a new revision of the original paper. The author Matthew Bentley finishes with this, quote, In summary, we request that Hive be put back on the agenda for C++23. There are other papers which are much longer but have had considerably less oversight, which are now in progress for C++23, and we consider this egregious." Instant update from Bryce Lelbock, who replied on GitHub. We're a week away from C++23 design freeze.

We can't consider adding more things to the plan for C++23. So, StatHive is not going to make it to C++23, unfortunately. I hope the author doesn't get discouraged by this. Scalable reflection in C++. This is revision 2 of the paper. This revision was harmonized with other papers in this area and adopted a new syntax proposed in another paper, replacing

Reflexpa with the caret operator. Also, a notable change is the replacement of the term reification with splicing. At the very least, it's easier to pronounce, in my humble opinion. Splicing is turning reflections into ordinary C++ source constructs. Quote. Earlier versions of this paper were more exploratory in nature. This version

uses experience with implementations based on earlier versions to narrow down a first set of metaprogramming features that are primarily aimed at providing reflection facilities with splicing and ordinary template instantiation handling generative programming. However, additional facilities, particularly for code injection, have been explored along with this proposal, and we are not confident that they can be added incrementally on top of this proposal. The first and most complete is a fork of Clang by Log3 Software by, among others, Andrew and Wyatt, authors of this paper. It includes a large portion of the capabilities presented here, albeit not always with the exact syntax or interfaces proposed.

In addition to these capabilities, Log3's implementation supports expansion statements and injection primitives, including fragment support. Log3 is not currently maintaining this implementation, however. The second is based on the EDG frontend by Faisal and David, and is less complete. It implements the reflection operator and most single splices, but not the pack splices, and a few meta-library interfaces. It does not currently implement features in other proposals like expansion statements or injection primitives.

Abbreviated parameters Quote abbreviated parameters quote this paper suggests alternative way of declaring parameter lists one that lets us omit parameter types what? if a parameter list starts with double parentheses then all single identifiers are not types but variables instead

hello kinder see are not types but variables instead. Hello, Kinder C! This paper also talks about omitting parameters altogether and leaving just commas. Really not sure about this one. C++ can be hard to read as is. Let's maybe not make it harder? StatBreakPoint. This paper proposes a new library function StatBreakPoint that stops program execution under debugger. Compiler-specific functions like that exist already. DebugBreak in MSVC, built-in trap in GCC and built-in debug trap in Clang. It would be a useful function to have in the standard library for situations where using IDE or a debugger UI to set a breakpoint is difficult.

A related paper, StudIsDebuggerPresent, that checks if a program is being debugged to aid in software development. The first thing that comes to mind as a use case is not to allow a protected program to run under debugger to prevent software copy protection or licensing code from being cracked. It will still be cracked. Contract support. Working paper. Okay, so this paper doesn't propose anything new. Is its purpose to revive the effort or to be the driving paper for contracts? Quote, we propose that there are two modes that a translation unit can be translated in. No eval compiler checks the validity of expressions in contract

annotations, but the annotations have no effect on the generated binary. And eval and abort. Each contract annotation is checked at runtime. The check evaluates the corresponding predicate. If the result equals false, the program is stopped. Many think that this is unacceptable. If a program cannot possibly terminate, these modes mean it cannot use contracts, or any libraries that use contracts, and that would include the standard library.

I guess we'll see how it goes and if it gets into C++ 26. Module status. A Redditor asks, what's up with modules? Quote, I know MSVC allegedly has a feature-complete support for C++20 modules, but that doesn't mean much for cross-platform projects. There isn't much related discussion for CMake and GCC, not here, not on Stack Overflow, nowhere. And from the little there is, I gather that it's mostly in such an early experimental phase that no one encourages using the feature. The MSVC team communicates their plans and status regularly, even joining the discussion on

this sub. But other teams are eerily silent. Have users lost interest in modules? Have compiler devs, build system devs lost interest or did they run into major problems? Niall Douglas replies The real blocker for most people is CMake build support, I think. And they're blocked on the compilers emitting the right modules build metadata so they can implement CMake build support. It'll come eventually, maybe a year or two more. Gabriel Dos Reis says, quote,

Interest in C++ modules are stronger than ever. We need, indeed, widespread build system support, e.g. in CMake. The SG15 tooling study group has adopted a format for specifying source level dependencies useful outside module uses. Also implemented at MSVC. I would love to see more progress in GCC and Clang for the benefit of the C++ community.

Looks like MSVC is ahead of all the big compilers in module support, but it's not all roses either. This Redditor says, Visual C++ has huge amount of bugs in module implementation. At least Boosterware projects couldn't be ported on modules. For example, I have three module bugs in Visual Studio Bug Tracker, and they are all about three months in investigation status so you can become yourself msvc modules are not okay now end quote from from the replies same i tried porting four cpps in real code based modules got ice in three of them. Some more bugs.

Yep, from my coding exercises I would add the following issues. Out macros and other stuff when Windows headers get imported. Precompiled headers cannot be enabled in projects that use modules. Lots of coffee time when using C++ WinRT with its pile of template magic generated out of ideal files. In teleSense, pressing F12 on a module symbol might just kill Visual Studio. Currently there is no plan on how to import stuff that depends on several macros to control their behavior. For example, iterator debug

level macro in MSVC. However, it is still the best experience versus GCC or even Clang that apparently is still stuck with classical Apple Google modules from what I understand from existing docs." End quote. Say you are starting a new cross-platform project. You are choosing a build system. So what are your options if you want to support C++ modules? CMake, in development, waiting for compiler support. Build2, full support for modules with GCC, announced in February 2021.

However, GCC didn't support modules very well back then, so how would that work? Mison at the design discussion stage. Bazel at the design discussion stage. Some experiments taking place. Premake supports MSVC modules, and there is a proposal for GCC support. Xmake. supports MSVC modules and there is a proposal for GCC support. XMake Full support for modules with MSVC, GCC and Clang with examples.

What? I haven't tried this, but it just sounds too good to be true. What is XMake anyway? GSL4 is available now. Microsoft's Guideline Support Library has hit version 4. The code is on GitHub. It is cross-platform, requires C++ 14,

and is distributed under MIT license. You can install it by downloading from GitHub or by using Microsoft C++ package manager VC package. It even has a custom debug visualizer for Visual Studio users. Best CPU versus GPU 879 GB per second reductions in C++. This article iterates through various methods to speed up calculations in C++ using vectorization and parallelization on CPU and GPU. The author provides code snippets that add one gigabyte of floating numbers together and their throughput data. Let's see what are the results.

Plain-C and STL around 5., around 17 to 22 GB per second. OpenMP, 5.4 GB per second. There is an update on OpenMP after the article was written, and after a few recommendations on Reddit an issue with compilations flags was resolved. At 100 CPU utilization

OpenMP scored 51 GBps. After that we disabled dynamic scheduling and reduced the number of threads reaching the result of 80 GBps. Parallel algorithms based on Intel's Threading Building Blocks. 80 to 87 GBps.

SIMD plus threads. 89 GB per second. The author writes, in the best-case scenario, if you always had a thread pool around with around 20 idle threads, we could do even better, up to 200 GB per second. When you switch to GPUs,

the result becomes very impressive. So if you use CUDA, the result is 817 GBps. And if you use the Thrust library, the result is 743 GBps. A 9% reduction compared to the handwritten kernel but hardly slow. But the huge advantage is that the code compared with the CUDA code, which is like incomprehensible, reminds of a normal standard library based code. If you use CUB, which main benefits is stricter control over memory allocations, you can manage the top result in this article, which is 879 gigabyte per second. Let's look at Thrust. So Thrust is a parallel algorithms library which

resembles the C++ standard template library. Thrust's high-level interface greatly enhances programmer productivity while enabling performance portability between GPUs and multicore CPUs. Of all the above, based on the presented code snippets, I would definitely choose thrust over anything else that was mentioned in the article. That's it for today, and let me leave you with these two tweets. Be positive. Use programming positive language.

Don't say arbitrary code execution vulnerability. Do say surprise extension API. Don't say protected data got leaked. Do say surprise remote backup. Thanks for joining me today. Until next time.