Home » Blog » Categories »

No Diagnostic Required Episode #0 -- Anastasia Kazakova and Phil Nash

By Anastasia Kazakova | Dec 9, 2020 12:54 PM | Tags: None

No Diagnostic Required, YouTube Show for C++ Annotated, Episode #0

No Diagnostic Required, Episode #0

by Anastasia Kazakova and Phil Nash

In this episode:

  • Welcome
  • New C++ podcasts worth following
  • ISO C++ Trip Report by Herb Sutter
  • Modules support in Visual Studio… and in GCC 11!
  • Qt6 libraries via Conan
  • CLion 2020.3: It’s all about debug!
  • ReSharper C++ 2020.3: The perfect game dev companion for Unreal Engine!
  • std::visit is everything wrong with modern C++

CLion 2020.3 release: Improve the way you develop in C++! -- Anastasia Kazakova

By Anastasia Kazakova | Dec 9, 2020 12:05 PM | Tags: None

CLion 2020.3 is released!

CLion 2020.3: Core Dumps Debug and Debug as Root, CTest Support, MISRA Guideline Integration, and a Better Qt Project Experience

by Anastasia Kazakova

CLion 2020.3 brings significant improvements to key parts of the development process – code analysis, running and debugging applications, and unit testing.

  • Run and Debug:
    • Run/Debug with Root privileges
    • Debug core dumps
    • Move the execution point while debugging to an arbitrary line of code in the editor
  • Project models
    • For Makefile: support for projects using libtool, dolt and ccache
    • For CMake: enable/disable CMake Profile
  • Unit testing: CTest support and test runner improvements for Google Test
  • Code analysis and refactorings updates, including initial support for MISRA C 2012 and MISRA C++ 2008 guidelines
  • Better Qt projects support
  • Clang completion snippets
  • An early preview for Code With Me, a new service from JetBrains for collaborative development and pair programming.

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...