On 25/05/2019 01:41, Erik Thiele wrote:
I assume that time_duration is implemented as an integer. Some values of this integer are then reserved for special values like not_a_date_time.
this can be seen here:
https://github.com/boostorg/date_time/blob/develop/include/boost/date_time/i...
Yes, that's what I said before.
this should have the consequence that when studying the assembler code for comparing two time_durations, all that happens is the assembler code of "less than compare" for integer type. if additional comparisons and branchings take place, then I assume the code is not meeting the design criteria of being optimized.
No. That would be true if it were just delegating directly to the underlying integer comparison (which, FWIW, is what ptime does). int_adapter, however, intentionally performs a more complex comparison in order to treat the special values as special, and thus in an order different from their underlying integer "implementation detail". In particular, not_a_date_time is implemented as a NaN-like "not in any order". (For the purposes of sort, this tends to make it equivalent to any other value, and thus it can sort to anywhere at all in the list, usually remaining motionless.) Have a look at the implementation of int_adapter::compare in the above code. Whether this is the "right" choice, I don't know. But it's how it works, and it appears to have been intentional.