No, just _if_ and _switch_ statements. _While_ with initializer is unnecessary as it would just be _for_ without the incrementer: for (auto foo = func(); cond; ) www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r1.html
@@MeeloOrg For C++20, for loops actually did end up getting an initialization statement for range-based loops: for (auto foo = func(); auto & : foo) { ... })
class A { std::strong_ordering operator (A rhs) const { .... }; bool operator == (A rhs) const = default; }; What does the defaulted equal operator do? Does it call the overloaded spaceship or does it compare all members?
It needs two arguments, but when you do something like `template ` this translates into `template requires std::totally_ordered_with`, i.e. the first argument is the template parameter type.
What's the spec, then? Less, 0? Could speak to dotnet IComparable.CompareTo, for instance; docs.microsoft.com/en-us/dotnet/api/system.icomparable.compareto
No, two values are *not* necessarily equivalent just because !(a < b) and !(b < a). Super simple example, I have a directed acyclic graph and I have an ordering on its nodes "a < b" meaning "there is a path from a to b". It's not uncommon to have !(a < b) and !(b < a), i.e. there is no path from one to the other, but that doesn't mean they're equivalent - in particular, given !(a < b) and !(b < a) it's still perfectly possible for there to be a c with (a < c) and !(b < c), which should not be the case if we're now claiming a == b. Ordering does not on its own imply a meaningful equivalence relationship. And let's also not pretend this is a pathological example. Graphs and ordering things on graphs is CS 101 stuff, and it's not like graphs are the only kind of thing where this happens. (Also I'm aware you could extend an ordering like this to a total ordering (for finite graphs anyway), and you'll often end up doing this - but, importantly, you *don't* do this by pretending things that are incomparable in the original ordering are actually equal!) This guideline should be scrapped, it's actively harmful. !(a < b) and !(b < a) being equivalent to a == b is only true if there is a meaningful equivalency (i.e. forall a b x. a == b => (a < x b < x) and (x < a x < b)) to begin with.
There's std::partial_ordering for that, can return that. In particular, spaceshipping two floats yields std::partial_ordering, returning std::partial_ordering::unordered whenever NaNs are involved.
'"a < b" meaning "there is a path from a to b"' Don't do that. Overloading comparison operators as shorthand for complex functions like "is_path_to" is just a bad use of overloading. If you want to sort by complex criteria like that, this is why all of the sorting functions allow you to pass a comparison functor. Using `operator
Great talk, through and through.
I commend the uploader's workaround for the < & > chars not being allowed in the title
This gave idea to do same for others operations like + * - / … by using algebraic structure; because a type or class look like a set have operator.
20:50 I suppose that's new with C++17, did not know you could initialize variable in an if statement. Same is true for while condition?
No, just _if_ and _switch_ statements. _While_ with initializer is unnecessary as it would just be _for_ without the incrementer: for (auto foo = func(); cond; )
www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r1.html
@@MeeloOrg For C++20, for loops actually did end up getting an initialization statement for range-based loops: for (auto foo = func(); auto & : foo) { ... })
class A { std::strong_ordering operator (A rhs) const { .... }; bool operator == (A rhs) const = default; };
What does the defaulted equal operator do? Does it call the overloaded spaceship or does it compare all members?
Can I put the possible results for the spaceship operator in a switch statement?
Sadly, no, it's not an enum.
When did the committee decide to separate equality from ordering? I like the new semantics for equality too.
trying the code std::totally_ordered_with needs two arguments, I must have missed a point somewhere (checked with cppreference.com)
It needs two arguments, but when you do something like `template ` this translates into `template requires std::totally_ordered_with`, i.e. the first argument is the template parameter type.
so it's a clamped "b - a" operator
What's the spec, then? Less, 0? Could speak to dotnet IComparable.CompareTo, for instance; docs.microsoft.com/en-us/dotnet/api/system.icomparable.compareto
11:17 return std::tie(lhs.x, lhs.y) == std::tie(rhs.x, rhs.y) your welcome. It would be really great if would work with tuples
works with tuples. But this will give you a std::weak_ordering unless your type has , which is probably not what you want.
No, two values are *not* necessarily equivalent just because !(a < b) and !(b < a). Super simple example, I have a directed acyclic graph and I have an ordering on its nodes "a < b" meaning "there is a path from a to b". It's not uncommon to have !(a < b) and !(b < a), i.e. there is no path from one to the other, but that doesn't mean they're equivalent - in particular, given !(a < b) and !(b < a) it's still perfectly possible for there to be a c with (a < c) and !(b < c), which should not be the case if we're now claiming a == b. Ordering does not on its own imply a meaningful equivalence relationship.
And let's also not pretend this is a pathological example. Graphs and ordering things on graphs is CS 101 stuff, and it's not like graphs are the only kind of thing where this happens. (Also I'm aware you could extend an ordering like this to a total ordering (for finite graphs anyway), and you'll often end up doing this - but, importantly, you *don't* do this by pretending things that are incomparable in the original ordering are actually equal!) This guideline should be scrapped, it's actively harmful. !(a < b) and !(b < a) being equivalent to a == b is only true if there is a meaningful equivalency (i.e. forall a b x. a == b => (a < x b < x) and (x < a x < b)) to begin with.
There's std::partial_ordering for that, can return that. In particular, spaceshipping two floats yields std::partial_ordering, returning std::partial_ordering::unordered whenever NaNs are involved.
I am aware of that, however my guideline is still correct because of a later guideline: your operator
'"a < b" meaning "there is a path from a to b"' Don't do that. Overloading comparison operators as shorthand for complex functions like "is_path_to" is just a bad use of overloading. If you want to sort by complex criteria like that, this is why all of the sorting functions allow you to pass a comparison functor. Using `operator