C++ Club - Meeting #131

Episode Date: June 19, 2021

https://glebd.github.io/cppclub/CppClubUK-131-20210610.html

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 the meeting notes contain public information only. This is episode 6 for the meeting number 131 that took place on the 10th of June 2021. First, we have status of the networking TS. A Redditor is curious, does anyone have any updates on the status of the C++ networking TS? Redditor 14ned, Niall Douglas, a committee member replies,

quote, Last time I looked, it all depends on how COVID goes. If normal committee work resumes early 2022, there is a chance networking makes into C++23. If it's late 2022, there is very little chance. Currently, the C++23 standard looks like it will be a fairly light one, but given how severely curtailed the committee's productivity has been, I still think it's great. Anything got in at all. Equally, this probably means 26 will be a

correspondingly bumper standard. End quote. Then we have this very emotional and somewhat misguided reply from Redditor Plasmatic. Quote. Why do they need to meet up, in quotes, to basically just make decisions on things? They are presumably all tech people. We have video chat. Or heck, they could do what every other language does and, you know, use text platforms to discuss these things. When Rust or Python makes updates,

the people in charge of the language don't all need to be in the same room to make these things. When Rust or Python makes updates, the people in charge of the language don't all need to be in the same room to make it happen. Same thing for C Sharp, Go, Swift, Kotlin, and heck, even Java. Why is C++ special? Why do they need five-star hotels and vacation destinations

to talk about the future of C++? End quote. Another editor answers that basically it all boils down to being an ISO language and having to follow ISO processes, which as far as I am aware, have already been greatly simplified for C++. Also note that the languages listed by you

don't have any presence in many markets where the only option is between C, C++ and Ada. All ISO languages with certified compiler toolchains and language standard compliance. Then we have more from Niall Douglas. Quote. Late-stage, uncontentious proposals can make reasonable progress by teleconference.

Early-stage proposals all went to pause over a year ago. None have progressed, none can progress until on-site meetings return. I am unaware of any programming ecosystem upon which billions of dollars of existing infrastructure lie, which does not have multiple annual face-to-face gatherings. End quote. This is what Nile says regarding the hotel luxuries. Quote, Unless you go a day or two early, or stay after, you only see your hotel bedroom when

sleeping and absolutely none of any facilities nor surrounds. You most definitely do not see the location you are in during the meeting itself, which particularly sucks for Kona. End quote. Back on topic, SciSpy2 replies, Networking is dependent on executors. That needs to go first. And then Redditor GrassyCot expands on that. We need a standard interface to schedule async operations. While waiting for that, we have third-party solutions, and there are some links provided

in the show notes. One of those solutions is C-Star from ScyllaDB, which is an event-driven framework allowing you to write non-blocking asynchronous code in a relatively straightforward manner. Its support C++ 17 and C++ 20 comes with its own native user space networking stack and is distributed under the Apache 2 license. And then a well-known ASIO library is a cross-platform C++ library for network and low-level I.O. programming that provides developers with a consistent asynchronous model using a modern C++ approach. It can be used either as part of Boost or in standalone mode. There was a video by Robert Leahy in CppCon 2020, which is called

The Networking TS from Scratch – IO Objects. Next, we have yet another pamphlet about inlining. Thomas Luce writes on his blog Belay the C++, quote, I will try here to summarize all you need to remember about inlining given pros, cons and situations to use it and not to use it end quote

the author correctly points out that the inline keyword is a hint to the compiler which can ignore it and then he goes on through pros and cons and most of those assume that inlining actually happens, like the pros avoiding the function call overhead and cons code size bloat. This Redditor

says, quote, in modern C++ inline does not mean what you think it means. It currently is only used to be able to define the same function, global variable, or static member variable in multiple compilation units while satisfying the one-definition rule." Of course, inline being just a hint, the compiler is free to not inline the functions marked

inline, but even in that case, it allows you to keep function definition in the header file, which is useful if you have a header-only library. On the other hand, inline functions pollute headers and increase compiler memory requirements. Keep in mind that function templates are implicitly inline, so marking them inline is redundant. There is a compiler-specific keyword, forceInline, and the corresponding attribute, always underscore inline, which indicates that a function must be inlined. However, compilers are free to ignore that as well. There is also a compiler-specific way to never inline a particular function.

In GCC and Clang, it isattribute__noinline and in MSVC it is __declspec noinline. As I understand this attribute will always be honored by the compiler. With link time optimization, modern compilers defer inlining until the link stage, when they can inline functions even not explicitly marked inline. The article author writes, quote, Here is my advice. Don't use inline unless you are 100% sure it is called insider bottleneck. End quote. Given all of the above, this advice

doesn't make much sense. For something invented as a tactical solution for a particular problem with interrupt service routines that couldn't have function calls in them, the inline keyword turned out to be a language facility that gained additional meaning over the years and continues to draw attention and fuel discussions in the C++ committee to this day. I wanted to remind you that C++17 introduced another very handy use of the inline keyword static inline variables. They allow you to define static variables inside class declaration to avoid having to define them in the implementation file reducing redundancy. Next we have a library TOML for modern C++.

TOML++ version 2.4.0 was released and TOML is Tom's Obvious Minimal Language, a configuration file format for humans developed by Tom Preston Werner, the founder of GitHub. He doesn't work there anymore. The language is easy to read and understand. It allows comments and is widely supported. Implementations are available in C, C++, C-sharp, Java, JavaScript, Swift, Scala, Python, Ruby, and other languages. Toml++ is a modern C++ implementation using C++17 and C++20, released under MIT license. It supports JSON serialization, UTF-8, optional header-only mode, and works with MSVC, Clang, and GCC. The documentation is really nice, and conveniently, the author of Toml++ released a Doxygen wrapper

called Poxy that you can use to produce similarly formatted documentation. One nice feature of Poxy is its improved Doxygen configuration file, which uses, you guessed it, Toml. its improved Doxygen configuration file, which uses, you guessed it, TOML. As the author says in the Reddit thread, quote, While I can't take credit for the HTML generator itself, I did write an additional front-end layer for it that fixes various Doxygen bugs and oddities,

adds features and post-processes the HTML for extra fancy bits, end quote. So it looks like a really useful library. Consider using Toml for your next project's configuration. Next we have passing smart pointers in C++. Another article appeared on this well-discussed topic, this time by Pranay Kumar, who works at Adobe. His article is pretty much a rehash of Herb Sutter's guidelines in Guru of the Week number 1991 Smart Pointer Parameters

with added illustrations and diagrams. The guidelines include Don't pass a smart pointer as a function parameter unless you want to use or manipulate it, such as to share or transfer ownership. Express a sync function using a by-value unique putter parameter. Use a non-const unique putter reference parameter only to modify the unique putter.

Pass shared putter by value only when you are sharing ownership. Otherwise, use non-owning pointers or references. In practice, I've seen many codebases where everything is a shared putter. And as a consequence, every function takes a const shared putter reference because it has to pass it on to another function. Sometimes you get a circular reference somewhere in a sharedPutter and then, surprise, there's a memory leak.

Untangling these is often very time-consuming and involves the entire codebase. Note that passing sharedPutter by value is really expensive as it involves incrementing the atomic reference count which is slow. Regarding returning smart pointers, Pranay says, quote, If you really need to return smart pointers from a function, take it easy and always return

by value. End quote. This is a good advice, and it works well with factory functions that return newly created objects. If you return a unique putter from a function, it can be move-assigned to another unique putter or converted to shared putter for passing around. This is the sanest and most flexible way, and it also works with polymorphism. You can return a unique pointer to a derived class from a function that has return value of unique pointer to base. Pranay says this about return value optimization.

All modern compilers are able to detect that you are returning an object by value and they apply a sort of return shortcut to avoid useless copies. Starting from C++17, this is guaranteed by the standard. End quote. C++17 guarantees copy elision, which means that your class doesn't even have to have a copy constructor or copy assignment operator or the corresponding move member functions for RVO to work. Prior to C++17, even if no copying were actually to happen, compiler would require that the class

had a copy or a move member functions available. I found an article by Jonas Devlier that explains guaranteed copy elision in C++17. Quote, The main problem is that without guaranteed elision, you cannot get rid of the move and copy constructor, because elision might not take place. This prevents non-movable types from having functions that return by value, such as factories. Jonas also mentions a subtle issue with it. Quote,

Nothing changes for NRVO, or Named optimization in C++ 17 with guaranteed copy elision. This is because, as mentioned before, the change only involves PR values. With NRVO, the named value is a GL value. You can check out the Reddit thread on the original article for some insightful comments. Here is what C++ core guidelines say about it. Section R30. Take smart pointers as parameters only to explicitly express lifetime semantics. Section F7.

For general use, take T-star or T-ref arguments rather than smart pointers. Section R32. Take a unique putter of a widget parameter to express that a function assumes ownership of a widget. Section R33. Take a unique putter of widget ref parameter to express that a function receipts the widget. Section R34. Take a shared putter of widget parameter to express that a function is part owner. Section R35.

Take a shared putter of widget ref parameter to express that a function might receipt the shared pointer. And section R36, take a const sharedPtr of widget ref parameter to express that it might retain a reference count to the object. And again, if you want to write an article that is accessible to your readers free of charge, please don't use medium, which puts your articles behind a paywall. Next we have coding font. Cascadia Code 2105.24. I previously mentioned the new Cascadia Code font from Microsoft. It will be included in the Visual Studio 2022 preview this summer. A new version of the font has been released, and this time it has fancy italics.

Really fancy italics. Go download and try it out with your current text editor or IDE. It's really nice and very readable. Next we have vcpkg package search. vcpkg is a C++ package manager from Microsoft. It builds packages from source and now offers a search function on its official website, which allows you to find the library you need across approximately 1500 available recipes. The nice thing is, vcpkg is cross-platform. There is another unofficial website vcpkg.info

which lists even more packages currently around 1600. It's good to see C++ package management getting more attention. Next we have a library tst a test framework without macros for C++17 and C++20. Ivan Gagis announced on Reddit his new JTest-style unit testing framework, TST, that doesn't need macros, or needs just a few of them, and supports C++17. It's cross-platform and comes under MIT license. There is another testing framework without macros, boost.ut, which is not actually Boost. And Ivan wrote a comparison on the Reddit thread,

which shows TST favorably via boost.ut, but then that's not really surprising. To me, boost.ut, but then that's not really surprising. To me, boost.ut looks more polished and has much better documentation, but it requires C++20, which for many developers is still some time away. Both frameworks rely on std source location in C++20, but Fabio Fracassi posted an entire implementation of source location for GCC and Clang using built-in compiler-specific functions,

which are called built-in line, built-in column, built-in file, and built-in function MSVC, so double underscore file, double underscore, and double underscore line, double underscore macros are still necessary there until C++20. I use Google Test at the moment, and it's full of macros. When C++20 arrives, I will likely want to start reducing macro usage in my code, so these test frameworks should come handy. Next, we have a library called Flashlight. It's a fast, flexible machine learning library, written entirely in C++ from the Facebook AI Research Speech team and the creators of Torch and DeepSpeech.

It is well-documented, requires C++ 17, and is available on GitHub under BSD license. Flashlight has CUDA and CPU backends for GPU and CPU training. The included projects are automatic speech recognition, image classification, object detection, and language modeling. Flashlight features just-in-time kernel compilation with modern C++

powered by ArrayFire tensor library. The ArrayFire company are consultants for AI and GPU computing projects. Quote, ArrayFire accelerated computing library is a free general-purpose open-source library that simplifies the process of developing software that targets parallel architectures including CPUs, GPUs, and other hardware acceleration devices. ArrayFire is used on devices from low-powered mobile phones to high-powered GPU-enabled supercomputers, including CPUs from all major vendors, Intel, AMD, and ARM,

GPUs from the dominant manufacturers, NVIDIA, AMD, and Qualcomm, as well as a variety of other accelerator devices on Windows, Mac, and Linux. End quote. Flashlight is being actively developed. the last commit was just days ago. It looks like a capable and easy to use option for your AI and ML projects. Next we have a library RML UI. RML UI is a C++ user interface package based on the HTML and CSS standards. It is a fork of the LibRocket project, introducing new features, bug fixes and performance improvements. It is also well documented.

The most interesting thing about RML UI is that it doesn't need a web browser. It has its own layout engine, and it takes the HTML, CSS-like source files, and turns them into vertices, indices, and draw commands, and then you bring your own renderer to draw them. This is markedly different from all other web-like GUI libraries for C++, which tend to need a web browser to render the UI. Quote, and of course there is full access to the element hierarchy slash DOM, event handling, and all the interactivity and customizability you would expect. All of this directly from C++, or optionally from scripting languages using plugins. The core library compiles down to fractions of the size it takes to integrate

a fully-fledged web browser as other libraries do in this space. Aramal UI supports Lua for scripting, is cross-platform, and even has a runtime visual debugging facility. The user controls their own update loop, calling into Aramal UI as desired. The library strictly runs as a result of calls to its API, never in the background. Unfortunately, it seems that you have to handle user input yourself. Still, RML UI is a very impressive library. The sample gallery includes games and other interfaces. The library requires C++ 14 and is available on GitHub using MIT license.

That's all for today and I'll leave you with a picture. Well, I have to describe it in a podcast. The picture is titled I don't need to read the documentation. I can make it work. It's from a reddit thread, the link is in the show notes. What it shows is a guy with his mouth down the top of a teapot, blowing air into the teapot so that the tea emerges from the spout and ends up directly in a teacup on the table you have to see it go and check the the show notes so yes that's it for today thanks for listening and i'll talk to you sometime next week hopefully next week take care bye