CppCon 2015: John Lakos “Value Semantics: It ain't about the syntax!, Part I"
Why Stack Overflow recommends it
Stack Overflow users link it when answering questions on copying, equality, comparison operators and class design, to explain what a type's 'value' really means.
Recommended by 2 people across 2 different months, 2017 to 2020.
What it is
John Lakos's CppCon 2015 talk (Part I of a series) on what it means for a C++ type to have value semantics. He argues that value is about salient attributes and an abstract mathematical type, not about having a copy constructor.
What people said
Recommends BoBTFish · 2019-02 · Stack Overflow · on “std::set use of operator<”
What you are attempting to achieve violates the Strict Weak Ordering [LINK] requirement of std::set . Basically, if you have 2 numbers, and neither is less then the other, they must be the same! They can't also be different (when checked using some different syntax). All of your comparison operators should be defined consistently, so that there is a clear idea of value for your type. Which members of your type are salient , i.e. contribute to the value? There might be other members, but they should never be checked in the comparison operators. An example is std::vector . If two vector s both contain a, b, c , they are equal. They might have a different amount of storage space left unused ( v
Recommends AndyG · 2019-05 · Stack Overflow · on “Creating types with restricted properties”
Yes These "restrictions" you are talking about are called class invariants [LINK] and a class is a way to construct a domain object to restrict it to be valid. It's one of the primary motivations for using classes. Arno Lepsik recently gave an excellent talk at CppCon 2018 about this called "Avoiding disasters with strongly typed C++" [LINK] John Lakos also gave an excellent talk about this at CppCon 2015 called "Value semantics. It ain't about the syntax" [this video] A full answer to your question would be very long, so I hope this brief discussion is useful. One great example of this is Boost.Units [LINK] . If you've ever had to deal with programming scientific applications, then you know that
Cites AndyG · 2017-12 · Stack Overflow · on “Overloading gives me error: no match for ‘operator<’”
bool Event::operator<(const double& currentTime) const Defines the less-than operator for only the following situation: Event e; //... double d = /*...*/; bool result = e < d; NOT the following situation bool result = d < e; When defining these operators, you MUST define them both ways! Ideally define them both as non-member functions bool operator<(const Event& e, const double& currentTime); bool operator<(const double& currentTime, const Event& e); (Why nonmember functions? To improve encapsulation [LINK] ) John Lakos has a has a wonderful CPPcon talk [this video] where he says exactly this.
Cites alfC · 2020-04 · Stack Overflow · on “Is it considered good design to compare objects of different types?”
According to Stepanov's rules (see Elements of Programming), equality is tightly connected with copying (construction and assignment) (and also inequality). So, if the objects represent equal values then go ahead, make them equality comparable but think of these four operations at the same time (equality, [copy]construction, assignment and inequality). By extension, also conversion (cast operation or construction on the other side) back and forth from the different types. It is also implicitly connected to any "regular" function you can apply to these values. Stepanov defines two values to be equal if any (regular) function applied to them gives equal results. I would say also that, even if