Better Code: Exploring Validity in C++ - David Sankel - CppCon 2023
Vložit
- čas přidán 3. 06. 2024
- cppcon.org/
---
Better Code: Exploring Validity in C++ - David Sankel - CppCon 2023
github.com/CppCon/CppCon2023
Most developers have at least some notion of the meaning of object, state, invariant, value, and invalid. On the other hand, it can be surprisingly
difficult to precisely define these words in a way that matches both
intuition and common usage. This difficulty has even led to divergence within the C++ standard library!
This talk is a journey of discovery where we not only find satisfactory
definitions, but identify practical, good coding practices along the way.
At the end of this talk you'll be able to name implicit contracts,
understand the deep connection between move semantics and exception safety, and, in general, have a greater appreciation for the meaning of the programs we write every day.
---
David Sankel
David Sankel is a Principal Scientist at Adobe and an active member of the C++ Standardization Committee. His experience spans microservice architectures, CAD/CAM, computer graphics, visual programming languages, web applications, computer vision, and cryptography. He is a frequent speaker at C++ conferences and specializes in large-scale software engineering and advanced C++ topics. David’s interests include dependently typed languages, semantic domains, EDSLs, and functional programming. He is the project editor of the C++ Reflection TS, Executive Director of the Boost Foundation, and an author of several C++ proposals including pattern matching and language variants.
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
CZcams Channel Managed by Digital Medium Ltd: events.digital-medium.co.uk
---
Registration for CppCon: cppcon.org/registration/
#cppcon #cppprogramming #cpp - Věda a technologie
Definitely one of the best 'better code' talks, just great work all around from the STLab!
Alternate title: Existentialism of Objects
Really fascinating talk. I like the idea of discardability, as it clearly allows for more efficient implementations in some cases. But I wonder if its definition needs to be slightly modified.
It's stated in the talk that an object in a meaningless/discardable state should *only* be destroyed or assigned to, and that moving from an object will leave it in a discardable state. Currently the standard requires that when types in the standard library are moved-from they will be left in a "valid but unspecified state.". That's obviously a stronger requirement than mere discardability. In particular it allows for a moved-from object to be moved-from *again* (although it will of course leave the moved-to object in a valid but unspecified state too). In fact that's a necessary property in order to ensure that for some meaningful object 'x', that std::swap(x, x) is well-defined.
There are three operations in std::swap(x, x), and for the operation to be well defined, none of them should involve UB. Assuming we were to adopt a model where moved-from objects are only discardable:
[1] T temp = std::move(x); // Leaves x in a moved-from state (i.e. it is now 'discardable')
[2] x = std::move(x); // We need this to not be UB. It can leave x in a discardable state, though.
[3] x = std::move(temp); // This restores the meaningfulness of x
For this to work, we need the self-move-assignment in [2] to not be UB. That is the only requirement. It's fine for it to leave 'x' in a meaningless state.
So my question is: Should the definition of discardability be updated to allow an object to be destroyed, assigned-to or *moved-from*?
I've since discovered that Sean Parent addresses this point in his note "Standard Library requirements on a moved-from object are overly strict" starting P807 in the book "Embracing Modern C++ safely". He asserts that the containers and algorithms in the standard library do not self-swap objects. He also says "There is no known value in supporting self-swap, and a self-swap usually indicates a defect in the algorithm." See also standards paper p2345r0: Relaxing Requirements of Moved-From Objects (2021)
28:18 of course there is a way for unique_ptr, do not provide .get(). force all raw access through .release() and reinstate (e.g. .reset) later if necessary.
For the question at 53:00 regarding a function named "get_value()", the function returns an object that has a value, or essence. It does not return a "value" as such, and that's the distinction.
Also, I think having "value" and "essence" as different terms can be useful; for the rational number case study, 1/2 and 2/4 have the same essence, but may be considered to be different "values" (albeit representing the same thing) to some programmers and so introducing a new, more specific term helps clear any confusion.
There is a useful distinction between value and essence. In code, one can say that vector.data() is part of the value (from a code perspective at least) but not part of the essence. The line between value and essence is aesthetic/utilitarian in general, just like the difference between valid and invalid. Of course if you want to say that value is the same as essence then at least one must accept the eventual existence of non-essential “parts” (usually for convenience, or legacy, or performance reasons). For example, a member of .numerator() and .denominator() that gives the internal (non-reduced) representation of a rational is a non-essential part of rational.
100% Value would indicate the actual data contained. But as he said, essence can be an equivalence class over substance / value.
I think there must be strictly not more cases of essence than substance. ie essence can be either equivalent to substance, or a 'summary' of it.
Maybe that's what the person commenting wanted .. just to deal with the quotient space and not be as concerned about the representation.
1:10 the talk starts here
That adobe ampersand always brings me life
I m looking for job as C++ developer; my background is mathematician
22:47 Sean Parent and Dave Abraham’s talk, referred by David: czcams.com/video/OWsepDEh5lQ/video.html
What if an object can be valid or not with respect to multiple functions? I can't buy the argument that `is_readable` will be better than `is_valid` in such case. For example, a file handle may be invalid with respect to a bunch of operations: close, read, seek, etc.
Arguably, the most common case is for objects to be invalid with respect to different contexts (functions) rather than one context.
If an object meets the preconditions of some of its public member functions and not of others, and supplies some “checker” about the one of those functions (e.g. read()) - I think it makes sense for the “checker” to be named appropriately (e.g. is_ readable()), and not use the generic “is_valid()” name.
In other languages the notion of “type states” makes it easier to encode an object’s state in the type-system (e.g. OpenFile opened = std::move(my_file).open();) in a manner that helps splitting different sets of of functions to different types, and get a clearer notion of validity for each type
@@Roibarkan But in your example, an object doesn’t meet preconditions of the ‘read()’ function and only this function. I argue, such “checkers” are bad API. Consider the following example: ‘if is_readable { read } if is_seekable { seek }’. If an object cannot be read from then it cannot be seeked and vice-versa. Programmers are lazy in a good sense, after a while they will start writing code like ‘if is_seekable { seek read }’ and so on. The point I was trying to make was that a sufficiently complex object will be invalid with respect to most of its operations. Otherwise it probably violates the single responsibility principle.
50 minutes for 5 min of obvious content
One more thing, secure_hash_map is kind of a bad example. It’s not meant to be understandable, it’s meant to be secure. The more obfuscated a thing is, the more secure 😂