On 23/05/2019 17:37, Erik Thiele wrote:
not_a_date_time is like a NaN. NaNs are weird like that.
i don't think we should mix floating point issues with the date_time library.
It's not implemented with an actual floating point NaN, but it is clearly intended to have equivalent behaviour. https://github.com/boostorg/date_time/blob/develop/include/boost/date_time/i... See the above code. Although interestingly unlike some floating point implementations, it looks like it does consider not_a_date_time == not_a_date_time. But yes, it should either give not_a_date_time an actual consistent relative ordering or use partially_ordered instead of less_than_comparable.
but i expect v0 and v1 to be equal because after sorting two vectors with the same contents must be equal. watch closely, v0 and v1 have the same elements. they are just push_backed in a different order. so after sorting v0 and v1, they need to be equal, but aren't. this is because operator< is not a complete partial order here.
Ah, I missed that part. But still, no. Sorting only uses operator<, and those operators are implemented consistently with NaN-like behaviour (partial ordering). In particular, it is *not* a "strict weak ordering", which is what std::sort assumes. not_a_date_time has no specific order, therefore sort is allowed to put it wherever it likes; you can't make any assumptions about its position relative to other values. It's not even required to group them together if they're spread out (although some sort algorithms might do that). If you don't like that behaviour, you can pass your own different comparator to sort which does assign a strict ordering to the values. For example, you can declare that not_a_date_time should be treated as strictly less than any actual duration. The bug you noticed in the <= and >= return values has no effect on sort.