Fix issues in Aux::Timer

[manpen]

Clang rightfully complained about Aux::Timer not having a virtual destructor.While fixing this, I spotted a number of additional issues, justifying a PR on its own.

This PR includes:

• A virtual destructor for Timer
• Most of Timer's methods are now const and nothrow (where applicable)
• A unit test for Timer
• A bug fix for elapsedMicroseconds() and elapsedNanoseconds(): The documentation stated that elapsed*() methods returned the time elapsed since the start and now (if Timer is still running) or
  between start and stop if the Timer was stopped. elapsed() and elapsedMilliseconds() behaved that way, while elapsedMicroseconds() and elapsedNanoseconds() only considered the latter case.
• Timer defined the macro my_steady_clock. While this should have been a using declaration not polluting global namespace.
• Add StartedTimer which is identical to Timer but does automatically call start() on construction.

Remarks:

• I do not see a reason to have virtual members in Timer and suggest to drop that (AFAICS its not used in NetworKit itself). But there might be external users. So I did not do it yet.
• I do know why code for MIC uses std::chrono::monotonic_clock
• To choice of returning a std::chrono::duration in integer milliseconds seems strange; but we cannot really change that now.

[avdgrinten]

I think we should just remove the virtual methods. Given that the methods return steady_clock::time_point, there is really no other implementation possible.

monotonic_clock was a name that appeared in earlier drafts of C++11, I guess that the Intel MIC compiler does not (or did not?) follow the updated standard.

[avdgrinten]

This class has no users. Do we need it? When / how will users be added?

[manpen]

I consider this a developing tool. I typically have a copy of this class in my source tree and remove it before pushing.

[avdgrinten]

In this case, would you consider renaming it to something like DebuggingTimer / DevelopmentTimer / LoggingTimer (or some bikesheded version of that)?

[avdgrinten]

In this case, would you consider renaming it to something like DebuggingTimer / DevelopmentTimer / LoggingTimer (or some bikesheded version of that)?

[avdgrinten]

I first I thought you were referring to the label. name -> named variable.

[avdgrinten]

This should use NetworKit's logging framework, e.g., INFO().

[manpen]

Thanks for your feedback. For a proper LoggingTimer I wanted the following features:

• User can provide loglevel at which it's active
• If the Timer is inactive it shoud be very cheap, s.t. we can leave it in the code (nb. calling std::chrono::*::now() roughly takes 2.5 us on my system, so you really want to deactivate it, if it's not going to be used).

To do so, I added two functions to Log.h:

• isLogLevelEnabled(loglevel) returns true iff the level will currently cause an output (duh!)
• Add LOG_AT(level, ...) and LOG_ATF(level, ...) macros which basically act like INFO and such but only with a user provided loglevel.

Note that based on LOG_AT(F?) all other macros are much easier to express ...

One "bug" the current solution has is that it will print the line number of the LoggingTimer's destructor if srcloc is enabled. The only solution around that is to provide the LoggingTimer via a macro which I do not really like. I consider this acceptable.

The PR also contains a mini-bugfix for a recently introduced signed/unsigned comparison; let me know, if I should separate it into its own PR.

(BTW: The diff of the force-push only is that large because I rebased to current Dev)

[avdgrinten]

Thank you for the revision. The LoggingTimer interface looks much better now; I think this has been a real improvement 👍. The whole PR LGTM.