Noexcept? Enabling Testing of Contract Checks in C++ - Pablo Halpern & Timur Doumler - CppCon 2023

cppcon.org/
---
Noexcept? Enabling Testing of Contract Checks in C++ - Pablo Halpern & Timur Doumler - CppCon 2023
github.com/Cpp...
Should `noexcept` be part of your function's contract? A function's contract is the set of pre-conditions promised by the the caller and the set of post-conditions promised by the function itself, including whether or not it throws an exception. Naively, then, it would seem that `noexcept` is a good way to indicate that your function does not throw when called in contract, but things are not so simple. In this talk, we'll review the original purpose of the `noexcept` specifier and the `noexcept` operator. We'll look at how runtime contract checks can be tested and how `noexcept` interferes with such testing. Along the way, we'll touch on the proposed contract-checking feature in C++26, eventually arriving at an alternative exception-specification annotation that would mesh far better with contract checking than `noexcept` currently does.
---
Timur Doumler
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 is organising the monthly C++ Helsinki meetup. Timur is passionate about clean code, good tools, low latency, and the evolution of the C++ language.
---
Pablo Halpern
Pablo Halpern is a freelance software developer and consultant. He has been programming in C++ since 1989 and has been a member of the C++ Standards Committee since 2007. His main contributions to the C++ Standard has been in the area of parallel and vector programming, and he is largely responsible for taking allocators from a curiosity in C++03 to a usable feature of the Standard Library in C++11 and beyond. He continues to work on language and library features to make allocator use simpler and less error prone. Pablo is the author of The C++ Standard Library from Scratch (Que, 2000), and is a major contributor to Embracing Modern C++ Safely (Pearson, 2021). He has given talks on a number of topics at the CppCon and ACCU conferences. Pablo lives with his partner in Boston, MA. When not working on books and allocators, he enjoys travel, model rocketry, biking, hiking, skiing, snowboarding, and watching opera.
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
UA-cam Channel Managed by Digital Medium Ltd: events.digital...
---
Registration for CppCon: cppcon.org/reg...
#cppcon #cppprogramming #cpp

[@niklkelbon3662]

49:37
preconditions - what before function
postcondition - what after function
So, why we need Lakos rule with 'function with preconditions are not noexcept' ? Is this mean runtime checks will be in function, while they should be before/after function call?
It adds new semantic to noexcept, ofc commitee can use this rule, because implementation may throw exception on undefined behavior (such as bad array access), but we rly dont need this rule in contracts
Also, i dont see why 'handle_contact_violation' function should be so specific as destructors (noexcept by default)
Im waiting for contracts because of optimizations and static analysis based on them, not for runtime checks (i already have 'if', thank)
What if different libraries define 'handle_contract_violation' in different ways? Will it be possible to compiler to understand what this function do to optimize?
There are few ways to handle contract violation:
* do nothing
* runtime check
* log + terminate
* undefined behavior (assume)
throwing exceptions IS NOT a way to handle BUG in your program. I dont want to see how some 3d party library uses contract violation exceptions for managing control flow

[@digama0]

Didn't the presenters give a pretty good argument for why exception passing is the only viable way to have asserts that don't cause UB or kill the process? The testing framework really is "using contract violation exceptions for managing control flow" for a good reason. I can't think of any other reason you would want to do this in a library, but this example looks well motivated.

[@kuhluhOG]

another way to handle contract violations:
returning std::expected

[@Ariccio123]

21:38 I'm a little surprised there's no discussion of the very similar concepts applied for compile time contract checking annotations like SAL - IMO the syntax there is pretty good and well tested by way of extensive use internally in Microsoft!

[@classone7101]

They stopped using it for their c++ library.
From what I see it's only in the legacy code of C now.

[@MonsSeptime]

Close the comments don't just delete them :) C++ sucks.

[@VFPn96kQT]

Thanks for your stupid feedback.

[@rutabega306]

Lol what happened

[@miroaja1951]

aren't you just a spark of joy