Home » Blog » Categories »

Feature Testing with C++20--Rainer Grimm

By Adrien Hamelin | Dec 8, 2020 01:20 PM | Tags: c++20

Use all that you can.

Feature Testing with C++20

by Rainer Grimm

From the article:

When your program's compilation broke with a brand-new C++20 feature, you often end with a few questions: Did I something wrong? Did I found a compiler bug? Does my compiler not yet support this feature? Thanks to the feature testing in C++20, the last question is easy to answer...

Remembering Beman Dawes

By Bjarne Stroustrup | Dec 4, 2020 09:47 AM | Tags: None

Remembering Beman Dawes

by Bjarne Stroustrup and Herb Sutter

beman.jpgOn December 1, we lost Beman Dawes, one of the most influential people in C++’s history. The C++ committee and communities, and we personally, owe Beman a lot. Although no funeral is planned because of Covid, we can all keep Beman and his many contributions, and his wife Sonda and their family, in our thoughts at this difficult time.

Beman was a member of the C++ standards committee (WG21) since 1992 and chair of the Library Working Group for five years during the completion of the first C++ standard, C++98.

I (Bjarne) remember that in 1994, the adoption of the STL into the standard was most uncertain because many doubted its utility and feared its novelty. At a critical point, Beman spoke up and calmly explained to the committee that he had thought the STL too complex for ordinary programmers, but as an exercise he had implemented about 10% of it himself so he no longer considered it beyond the standard. It can be argued that the STL and the techniques it pioneered saved C++ as a living language. Without Beman, this may very well not have happened.

Beman was the original developer of <filesystem> and shepherded it through its tortuous path into the standard. When it mattered, he could be patient.

Boost was an “invention” of Beman’s as a cofounder with Dave Abrahams and soon many others. Like many, Beman decided (correctly) that lack of quality libraries was a startling weakness of C++ — we had and have an incredible number of libraries, but they have no shared style and often don’t easily interoperate. Beman’s key idea was to create a community around the development of libraries that could complement the standard library. Many of the most successful Boost libraries are now part of the standard and used world-wide. In support of the community idea, Beman was one of the founders of BoostCon (later called C++ Now). That conference created an important early hub where the people working on further evolution of the C++ library and language after the first standard could meet to socialize and exchange ideas, a culture that has grown broader and now flourishes at a number of conferences.

We have relied on Beman's skills and wisdom broadly: When the Standard C++ Foundation was created in 2012, Beman was one of the founding directors along with us. When WG21 created the Library Evolution group in 2013 to have a separate group be responsible for the overall design of the C++ standard library, Beman kindly agreed to step up to be its founding chair to get it started on the right foot and find his own replacement. When WG21 created the Direction Group in 2017 so that we could have a small group of the most wise and respected C++ experts in the world to recommend direction for C++ evolution, Beman was a natural choice to invite as a founding member, and we are glad he accepted that too.

Clearly, every C++ programmer owes a debt to Beman. He was an experienced application developer who brought his insights, skills, and energies to the standards committee. Without him, C++ would not be what it is today.

On a personal note, I (Herb) attended my first WG21 meeting in summer 1997. Even then when the committee was smaller, it was a pretty intimidating thing to be an unknown person showing up unannounced to a gathering of the Who’s Who of all the world-class experts I had known only from their books and reputations. Among many who welcomed me, Beman was key — I spent most of my time there in the Library group, Beman’s group, and all I felt qualified to do was sit and listen and absorb how things worked. Beman personally, and the warm culture he fostered in his group, made me feel comfortable and welcome enough that I learned a lot that week, attended another meeting, and another, and never quite stopped.

Thanks, Beman. Thank you, very much, for your enduring contribution that has benefited so many people.

The Code Analyzer is wrong. Long live the Analyzer!

By Andrey Karpov | Dec 1, 2020 10:53 AM | Tags: unspecified behavior undefined behavior std::move static code analys pvs-studio code review

Combining many actions in a single C++ expression is a bad practice, as such code is hard to understand, maintain, and it is easy to make mistakes in it. For example, one can instill a bug by reconciling different actions when evaluating function arguments. We agree with the classic recommendation that code should be simple and clear. Now let's look at an interesting case where the PVS-Studio analyzer is technically wrong, but from a practical point of view, the code should still be changed.

The Code Analyzer is wrong. Long live the Analyzer!

by Andrey Karpov

From the article:

As you can see, once upon a time std::make_pair was taking arguments by value. If std::unique_ptr had existed at that time, then the code above would have been indeed incorrect. Whether this code would work or not would be a matter of luck. In practice, of course, this situation would never have occurred, since std::unique_ptr appeared in C++11 as a replacement for std::auto_ptr. Let's go back to our time. Starting with C++11, the constructor started to use move semantics.

Under the Covers of C++ Lambdas: Captures, Captures, Captures--Andreas Fertig

By Adrien Hamelin | Nov 30, 2020 01:05 PM | Tags: advanced

Lambdas.

Under the Covers of C++ Lambdas: Captures, Captures, Captures

by Andreas Fertig

From the article:

Lambda Capturing syntax allows us to quickly “wrap” a variable from the outside scope and then use it in the lambda body. We also know that under the hood the compiler translates lambda into a closure type… but what happens to those captured variables? Are they translated to public data members or private? See the newest guest post from Andreas to understand this tricky problem...

Capture *this in lambda expression: Timeline of change -- Hitesh Kumar

By Hitesh Kumar | Nov 30, 2020 11:22 AM | Tags: None

The current object (*this) capture in a lambda expression has gone through some changes since C++11.

Capture *this in lambda expression: Timeline of change

by Hitesh Kumar

From the article:

A lambda defined inside a non-static member function can directly access the members of the current object (or its copy) via an appropriate capture clause. But how the current object can be captured has gone through some changes since C++11.

I/O Prioritization in Windows OS -- Milad Kahsari Alhadi

By Milad Kahsari Alhadi | Nov 30, 2020 11:19 AM | Tags: None

In this paper, I am going to discuss how can we as the application or device driver developers take advantage of I/O prioritization in the Windows OS.

I/O Prioritization in Windows OS

by Milad Kahsari Alhadi

From the article:

I/O prioritization improves the responsiveness of the system without significantly decreasing the throughput of the system. Typically, any topic related to I/O and threads requires a good understanding of Windows synchronization because of that, I will try to discuss everything from the ground up.


In this paper, I am going to discuss how can we as the application or device driver developers take advantage of I/O prioritization in the Windows OS. Finally (in the next paper, I will discuss the I/O completion mechanism of Windows) which is a magical feature.