Timur Doumler - "Contracts for C++" - C++ London

Recorded live at the C++ London meetup at Maven Securities, March 2024
www.meetup.com/cpplondon/even...
(Please note, this was recorded using a backup approach so has a number of compromises on audio and video quality. In particular the mic was an open room mic that picks up a lot of room noise.)
Design by Contract is a very effective approach for writing safer, more correct programs. It has been successfully implemented in programming languages like Eiffel and Ada. Attempts to add a Contracts facility to C++ have a long and storied history spanning two decades. Since the last attempt to standardise Contracts (for the C++20 Standard) has failed, SG21 - the Contracts Study Group on the C++ Standard Committee - has been working on a new design, the so-called Contracts MVP, which is now essentially feature-complete and on track to make it into the upcoming C++26 Standard.
In this talk, we present the current design of the Contracts MVP targeting C++26. We discuss preconditions, postconditions, assertions, contract-violation handling and much more. We consider how the Contracts MVP provides a superior replacement for custom assertion macros and, when used correctly, can significantly improve the safety and correctness of your code.
---
Timur Doumler is the co-host of CppCast and an active member of the ISO C++ standard committee, where he is currently co-chair of SG21, the Contracts study group. Timur started his journey into C++ in computational astrophysics, where he was working on cosmological simulations. He then moved into the audio and music technology industry, where he has been working for over a decade and co-founded the music tech startup Cradle. In the past, Timur also worked for JetBrains, first as a developer on CLion's C++ parser and later as a Developer Advocate for C++ developer tools. Currently, Timur lives in Finland, where he works as an independent consultant and organises the monthly C++ Helsinki meetup.

[@vladp72]

Thanks for the great summary of where the feature is. I am wondering if we should split pre/postconditions that are thread safe vs non-thread safe. For example, if pre/post conditions reference a private variables and implementation of that class takes care of locking inside method definition then evaluating pre/postconditions during runtime will result in UB since it will be happening outside of the scoped lock declared in the function's definition. That would mean we can never enable run time checks on multithreaded programs. If we can split preconditions that are thread safe, then we can enable a subset of pre/postconditions.

[@vladp72]

Never mind, around 1:03 Timur made a comment that acquiring lock in pre/post is allowed.

[@aniketbisht2823]

9:30 Class invariants are something that the implementer of the class guarantees and the user of the class assumes to be true. So if there is a "violation" of class invariant then it's a bug in class implementation. The user need not "worry" about messing the class invariant. They only need to ensure that the pre-conditions of the class method they are calling are satisfied.
9:17 If you are "messing up the class invariant through reinterpret_cast", you're most likely invoking undefined behaviour by violating pre-conditions of some core-language feature.

[@Voy2378]

underwater audio

[@tiranito2834]

HD audio is still being debated by the standard committee and won't be introduced in the standard until at least C++29

[@ABaumstumpf]

@@tiranito2834And then they will decide on an obscure codec not in use since the 90s with 5:3 and 123p as the default resolution with 7bit mono audio.

[@kodirovsshik]

@@tiranito2834🤣

[@embeddor3023]

-underwater- dogwater audio

[@milasudril]

Hmm, virtual functions are just function pointers under the hood. if you solve it for function pointers, you should get it for virtual functions for free, so maybe you should try to extend the facility that you are working on for virtual functions, so you can have it on function pointers as well.

[@sanjaygatne1424]

Poor sound quality.