Meta Polymorphism - Jonathan Boccara - Meeting C++ 2020 Opening Keynote
The opening keynote of Meeting C++ 2020
Meta Polymorphism
by Jonathan Boccara
December 2020
Remembering Beman Dawes
Remembering Beman Dawes
by Bjarne Stroustrup and Herb Sutter
On 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!
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.