Re: [boost] Low-level precision timer proposal - Part II

From: Philippe Vaucher (philippe.vaucher_at_[hidden])
Date: 2006-07-18 08:47:53

>
> I'm afraid I didn't make my point clear. It wasn't about supporting
> BOOST_NO_EXCEPTIONS (which I'd like not to --it would require in any
> case a re-examination of the code, as I didn't design it with that in
> mind). It was to discuss what type of exception(s) we want to throw
> and what additional info, if any, we want to add to exception objects.
> Maybe Boost.Date-Time already has a well thought-out solution.

Then I have no clue for this :)

I'm not sure we are understanding each other. The main advantage of my
> solution is that it doesn't logically imply/require any usage of a
> "time point". That means: if you measure while someone (or some
> program/service) adjusts the system clock, or a DST switch happens,
> you are *not* affected.

We are, it's just I copy pasted too much for my example. My point was mostly
for the clock_device and the time_duration_type that should be able as
typedefs.

>------------------------------------------------------------------------------
> >void resume(); // gps - what if you call twice pause, twice resume
> >consecutively??
> >// bool is_running() const // gps - add this??
> >// gps: I see no point in having clear_elapsed()
> >
> >I think calling twice pause or resume should have no effect.
>
> Maybe.

It's not a media player where the interface tries to be friendly and
pressing pause toggles play/pause, it's a timer where pause means pause no ?

>Not doing so is
> >too error prone imho.
> >is_running() sounds like good idea tho I can't really think of a use for
> it
> >so maybe not if that means having to add a data member to implement it.
>
> Basically you are saying you are in doubt. I was too, hence my
> question (incidentally: what's your concern with an additional data
> member??).

I'm just explaining why it's a doubt yes. The concern about an additional
data member is silly but it's something about if the feature is never used
and the object gets bigger then it's just lose-lose. But after more thinking
is_running also helps the implementation clarity so I think we'd add it.

>I think reset() was good, why don't you see a point for it ? If you want to
> >time two consequent things individually and use the same object ?
>
> restart()?

Restarts resets and starts again, it's two actions. You don't provide the
1st one.

>------------------------------------------------------------------------------
> >template <typename D>
> >void elapsed_timer<D>::start() // may throw
> >{
> >    restart(); // this is just the same as restart();
> >               // maybe we can come up with a common name -gps
> >}
> >
> >I think calling start() twice should not reset it, I think restart should
> >call reset() then start().
>
> Honestly, did you really look at my code? Looks like you keep thinking
> in terms of yours. I had no concept of reset() at all.

Maybe I wasn't clear: I said your interface lacks the reset() concept, and
that restart() should be reset() then start().

>Again, I think pause should pause if not already paused, otherwise do
> >nothing, like the implementation I uploaded based on Jeff's design.
>
> I see. But the point is: if the user code happens to call pause()
> twice without intervening restarts, is that a sign of a logical error?
> It's similar to set a pointer to null after a delete, to ensure a
> double deletion is harmless. It may make you feel safer, but in
> practice it hides programming errors by eating their immediate ill
> effects.

For me it's not an error. If the user wants to do cout.set_precision(23);
cout.set_precision(23); it's his problem :) What we could do is return a
bool that'd tell pause() success tho.

>------------------------------------------------------------------------------
> >// Specific Clock Devices
> >// gps - should this be copyable?
> >
> >Why not ?
>
> It's a choice, and I annotated it to make sure I gave it another
> thought at the end of the work.

It's usually a choice driven by the fact that copying it might be harfmul or
imply extra design decisions (resources etc) but here I don't see why it
wouldn't be.

>I also think your interface lacks the hability to set the initial time
> >offset, which could be usefull in some situations.
>
> Care to explain?

For the "I want to create a timer that starts with 100 second elapsed
already" kindof requests.

Philippe