Pragmatic Simplicity - Actionable Guidelines To Tame Cpp Complexity - Vittorio Romeo - CppCon 2022

---

Pragmatic Simplicity - Actionable Guidelines To Tame C++ Complexity - Vittorio Romeo - CppCon 2022

Minimizing complexity in a codebase provides invaluable benefits, especially at scale, including but not limited to: maintainability, ease of understanding, malleability, debuggability, and testability. Such benefits translate not only into real economical advantages, but also increase the mental well-being of any developer.

So, how can "simplicity" be achieved?

Rather than focusing on philosophical concepts, this interactive presentation will give developers pragmatic and actionable guidelines that can be readily applied to reduce complexity in any codebase. Starting from a wide variety of examples (e.g. casting, containers, looping, attributes) a set of precepts will be derived together with the audience. After that, a deep analysis of where those precepts fall short will be given, honing them until the reaching the final goal: obtaining actionable guidelines useful in the real world.

If any of the following questions sound interesting to you, then you will definitely find this talk helpful and enjoyable:

- Should `emplace_back` always be used instead of `push_back`?
- Does `[[nodiscard]]` belong on every pure function returning non-`void`?
- How can one decide between using open-set and closed-set polymorphism?
- Are regular `for` loops the best way of iterating over a range of numbers?
- Do C-style casts still have a place in Modern C++?
- Is `T*` really a valid replacement for `std::optional＜T&＞`?
- Does simple code imply concise code?
- Can using templates reduce the complexity of a code base?
- When does it make most sense to use type deduction?
---

Vittorio Romeo

Vittorio Romeo (B.Sc. Computer Science, 6+ YoE at Bloomberg) works on mission-critical C++ infrastructure and provides Modern C++ training to hundreds of fellow employees.

He began programming around the age of 8 and became a C++ enthusiast shortly after discovering the language. Vittorio created several open-source C++ libraries and games, published many video courses and tutorials, actively participates in the ISO C++ standardization process, and maintains the popular SFML library.

He co-authored the acclaimed "Embracing Modern C++ Safely" book (published in January 2022) with J. Lakos, R. Khlebnikov, and A. Meredith.

Vittorio is an active member of the C++ community with an ardent desire to share his knowledge and learn from others: he presented and offered workshops over 20 times at international C++ conferences (including CppCon, C++Now, ++it, ACCU, C++ On Sea, C++ Russia, and Meeting C++), covering topics of various nature.

He also maintains a website with advanced C++ articles and a YouTube channel featuring well-received modern C++11/14 tutorials. Lastly, he's active on StackOverflow, taking great care in answering interesting C++ question (90k reputation).

When he's not writing code, Vittorio enjoys weightlifting, playing volleyball, scuba diving, canyoning, gaming, and enjoying sci-fi content.
---

#cppcon #programming #cpp

[kevanschwitzer]

One of the most awesome-est things about CPP conferences compared to others is that they often have a nice QA section available on the videos posted online at the end. Great stuff! It's refreshing that it's OK to question the speakers points, the last question being a great example. Sometimes you wonder if you've watched too many CPP talks when you can tell who the members of the audience are (last was Fedor Pikus).

[ValentineOficial]

Honestly, I hadn't watched a C++ talk that felt "approachable" in a long time (besides Kate Gregory's). I tried using C++ for some small projects a couple of years ago, but the complexity of the language ended up pushing me away... it's nice to have some actionable advice to try to cope with the problem a little better. Thanks for the talk!

[PUZORS]

Interesting topic and themes to think! Really appreciate your ideas and thoughts. Thanks!

[joshuasanders]

Nearly all of these points I've been hearing for years from my co-workers who are much better engineers than I, pretty neat!

A lot of people seem to gravitate towards specific examples like "well what if in x case" but they're missing the point. The point is, reduce noise. If someone can reasonably expect your code to throw an exception, but the fact that it doesn't has important readability or performance implications, label noexcept. Otherwise, it's just noise.

[gast]

Indeed all these keywords make reading C++ code harder. Ideally 'noexcept' wouldn't be necessary and that the compiler could just determine itself.

[abuyoyo]

I don't agree with everything - e.g, I believe `final` has inherent value (allows the compiler to devirutalize methods) and I believe consistent style was proven to reduce mental friction when both reading and writing code - but overall great talk, well thought out and thought provoking.

[HaraldAchitz]

I appreciate the insights in this talk and the actionable guidelines provided. However, it's worth keeping in mind that simplicity can be subjective and can vary depending on the context. What may seem simple to one person may not appear that way to another, especially in different projects or scenarios. That being said, the guidelines presented here are a helpful starting point for taming complexity in C++.

[isodoublet]

I agree on most points except auto, where I think you are not being consistent with the application of your principle. If the idea is to minimize the possibility that some important information might get lost in a sea of equally important-looking information, surely that implies one should use auto _more_ often, rather than less: whenever you see it, you don't really care about the type of the variable on the RHS, and you just want the LHS to track whatever it is. Conversely, when you see something other than auto, it means you _do_ care about that type and you want to enforce it. That explicit type seems to me the closer conceptual analogue to the "speed limit" sign, rather than the mere appearance of a keyword. What that keyword affords is the separation of concerns between declaring an object and specifying its type.

[AlgoFodder]

Don't envy anyone up on a stage getting into an argument with Fedor Pikus!

[larwortsomv]

15:40 seems like logical gymnastics. push_back() means you need to think more about if it's appropriate than with emplace_back() (just like with a C-style cast you need to think harder to judge if it's appropriate than with static_cast). Your intent only needs to be expressed when you intend something potentially unexpected or ambiguous that is non-trivial. Expressing intent in ways that force a code reviewer to think needlessly is just as bad as failing to express intent when it IS needed.

[babgab]

46:00 "final" is a useful optimizer hint, though? It lets the compiler inline virtual functions if it knows the type hierarchy doesn't go any deeper. Gamedevs frequently care more about perf than code reuse and we actually enforce the use of final on polymorphic leaf types in code reviews so these optimizations can happen. Is this not a concern for anyone else?

[hymencallis]

Quite divisive talk, but also food for thought. However, I stand with Fedor on the noexcept argument. In my newer code, I mark every function that cannot throw as noexcept. If I see a function that is *not* marked noexcept, that signals to me that the function *can throw* and that I have to handle its exceptions when I'm calling it from a noexcept function. Moreover, if a function returns an error code (we have such oldschool code), it better be noexcept, because having two different error reporting mechanisms does not make much sense and overcomplicates things. For me, "noexcept" is an important part of the "contract" (as is its "const" sibling). Now, I better read up on "noexcept" pessimizing optimization...

[WilhelmDrake]

I couldn't disagree more on the use of' noexcept'.
noexcept is NEVER implied.

It's part of the interface. If I don't see it I assume the function can throw.
Regarding 'final', its use ensures that you adhere to Effective C++ ttem 33: Make Non-Leaf Classes Abstract
• Make Non-Leaf Classes Abstract
• Make Leaf Classes Final

[hiftu]

I don't write [[nodiscard]] for my fellow humans.
I put those there to make the compiler complaining about the usage of those functions.
I think that increase code quality. And I don't care if my fellow humans don't like those because code quality is more important than anyone's feeling.

[AnkurVarsheny]

And this is exactly the issue with C++ community. Instead of building higher level abstraction and constructs we are debating about which cast is better and people are still split. The greatest software we use today (Linux) is built without all this BS and it works just fine.