Re: [lmi] Using std::chrono::high_resolution_clock for Timer implementation

[Greg Chicares]

On 6/3/21 12:49 PM, Vadim Zeitlin wrote:
> 
>  I don't plan to do it immediately but, if you don't mind, I'd like to
> switch to using the standard class, available since C++11, providing the
> same resolution as gettimeofday()/QueryPerformanceCounter() that we
> currently use, but which is much simpler to use.

I never studied std::chrono in much depth, because all of lmi's
chronological needs are met, and also because this doesn't seem
to be one of the LWG's better efforts. For example, overloading
the division operator to mean a field separator is abusive, but
several dozen overloads is an outrage.

And consider an attempt to translate c++20 [time.cal.operators]
into plain English:

https://en.cppreference.com/w/cpp/chrono/operator_slash
| A plain integer is accepted if its meaning is unambiguous [...]:
| 2005y/4/5 is allowed, but 5/April/2005 is not.

That's just wrong: the first is either April 5 or May 4, so it's
ambiguous; but 5-April-2005 is unambiguous. The part I elided in
the quote above turns out to ambiguate the definition of ambiguity.

> In fact, one of the
> reasons I'd like to do it is to make Timer class fully inline, so that it
> could be used easily for temporary benchmarking of some code, even from the
> code which doesn't link with timer.o.

If temporary convenience in one source file you're working on is
the motivation, then would something as simple as

+#include "timer.hpp"
+#include "timer.cpp"

be enough?

>  Again, this is not urgent at all but I just wanted to confirm that you
> didn't have any objections to it before adding it to my TODO list/queue
> (actually I should probably switch to a hash soon, for better access speed,
> considering its size...).

What we have is familiar and well validated; why replace it?

Perhaps using a tiny part like std::chrono::high_resolution_clock
would be a good idea for the long term, as it would automatically
adapt to operating-system changes. That might even make sense in
the short term, if we can verify that the bindings to glibc and
msw are correct--for glibc, I don't think we'd even have to ask,
but for MinGW-w64, it's important to ask. Oh, but wait:

  https://en.cppreference.com/w/cpp/chrono/high_resolution_clock
| The high_resolution_clock is not implemented consistently across
| different standard library implementations, and its use should be
| avoided.

Of course, that's not normative, but it seems scary: it sounds
like if I decide I want a high-resolution clock (which I can
implement very well myself), but some implementation decides to
veto my decision, then they prevail. Shouldn't I just veto them
in advance by avoiding std::chrono?

And if we use std::chrono for this, what do we get when we ask
for the tick count? A 64-bit integer? No: std::chrono::time_point,
with a helper class std::common_type<std::chrono::time_point> and
so on. Why isn't that wrong? Why shouldn't it be as simple as an
integral tick count? I worry that using any part of std::chrono
introduces a taint that would tend to propagate.