Back to Basics: The C++ Core Guidelines - Rainer Grimm - CppCon 2022

cppcon.org/
---
Back to Basics: The C++ Core Guidelines - Rainer Grimm - CppCon 2022
github.com/CppCon/CppCon2022
Why do we need guidelines for modern C++? My answer boils down to three points:
1. C++ is complex for the novices
2. C++ is challenging for the professionals
3. C++ is used in safety-critical software
The C++ Core Guidelines are a C++ community-driven project by the editors Bjarne Stroustrup and Herb Sutter. They provide best practices for modern C++, including all important aspects of software development such as, for example, interfaces, functions, classes, concurrency, and templates. Applying the C++ Core Guidelines means writing correct software by design.
In my talk, I present the most important rules of the C++ Core Guidelines. My talk should not be your endpoint but your starting point for a more profound studying of their invaluable rules.
---
Rainer Grimm
Rainer has worked as a software architect, team lead, and instructor since 1999. In 2002, Rainer created a company-intern meeting for further education and had given training courses since 2002. Rainer's first tutorials were about proprietary management software, but he began teaching Python and C++ soon after. In his spare time, he likes to write articles about C++, Python, and Haskell and speak at conferences. Rainer publishes weekly on his English blog Modernes C++. Since 2016, Rainer has been an independent instructor, giving seminars about modern C++ and Python. Due to his profession, he constantly searches for the best way to teach modern C++. He published several books in various languages about modern C++ in the last ten years, including the last one "C++ Core Guidelines Explained: Best Practices for Modern C++".
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
KZbin Channel Managed by Digital Medium Ltd events.digital-medium.co.uk
#cppcon #programming #cpp

[@WilhelmDrake]

Thank you Mr. CppCon for making these lectures available. As someone, with minimal resources, attempting to teach themselves C++, I really appreciate it. Best wishes.

[@ultradude5410]

Ah technical difficulties Happens to the best of us lol

[@retiredreplicant.2195]

fantastic. Clear explanations. :)

[@MrAbrazildo]

16:00, I have not been seeing anyone saying that the so called "setter f()s" should not be public, as seen in Java culture and alike. This should be a core guideline.

[@phenixwutao]

I have read your book, nice one

[@OlliS71]

After 10s of hearing this english for runaways I needed medical treatment. But I still like his books on Leanpub.

[@guillermotomasini]

very interesting really.

[@user-wk8tq8qc1p]

I would totally be running and hiding in the woods should I have my code reviewed by him. Scary guy :) But the info is useful.

[@lukasz2345]

We have smart pointers for how long? And we still need to teach that :/ kzbin.info/www/bejne/i4CxfXVtrKeJicU

[@Webfra14]

It's C++. After each lunch break you have to get retrained on the fundamentals. And when they upgrade the standard, you have to learn a new language.

[@tatianaes3354]

@@Webfra14 Sadly, a correct joke. C++ has become a completely overwhelming dumpster fire of countless concepts and paradigms enough for a dozen of languages. And its high brow novelties require so much overhead management that sometimes people are at a loss when they can actually get to code their algorithms. In such circumstances, guidelines are probably unavoidable.

[@EyeNeo]

In 12:00 slide, there's mistake. Unique pointer is passed by value which is wrong, since unique pointers cannot be passed by value cause they can't be copied.

[@hymen0callis]

Not sure if a copy *has* to happen. There's also copy elision in modern C++ and the unique_ptr could be moved from inside func(). So, not a bug for me per se. (but I'm no expert)

[@masheroz]

14:13 he says the caller has to move the ptr in.

[@gast128]

You can move an unique_ptr; therefore exclusive ownership.

[@PaulDiracTWR]

You're supposed to func(std::move(ptr)) in the call to that function, I don't think there's a mistake.

[@HerrLleaf]

This signature is valid because the parameter can be move-constructed from an rvalue. This is called a sink parameter/sink function. It is exactly the "Impossible to copy" case explained in the previous slide.

[@hoanghungpham473]

It's an interesting topic but need a better way, quite hard to follow.

[@jens6398]

8:23 That's a strawman. The first signature has meaningless parameter names. Rename the parameters to *top, left, bottom, right* and the two versions become alike.

[@User-cv4ee]

I would find it easier to read the code if the call-sites looks like `rect({2, 5}, {11, 10})` rather than `rect(2, 5, 11, 10)`. The later leaves alternate interpretation of center coords with width and height.

[@cyrilanisimov]

Don't argue) He's been coding since 1999.

[@amayesingnathan]

That's part of the point that example is making of the core guidelines. It means a) use stronger types and b) use clearer variable names. It's all about intent.

[@Adowrath]

But what if you see a call to the function like rect(100, 100, 200, 200) and you don't have the definition present in your mind? How likely is it that you're not gonna rely on your gut instinct to say "Oh, starts at 100,100 and has a width and height of 200,200" you may have at that moment and instead go to the definition to check with the parameter names? Two explicit points still eliminates possible confusion in that case.