Re: [boost] [thread] Integration with Chrono and DateTime

Subject: Re: [boost] [thread] Integration with Chrono and DateTime
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-10-17 02:41:50

On Wed, Oct 17, 2012 at 2:24 AM, Vicente J. Botet Escriba
<vicente.botet_at_[hidden]> wrote:
> The single way I see to decoupling is:
>
> * to define a base class B that is independent of of Chrono and DateTime and
> provides a more restrictive time based interface using e.g. nanoseconds, and
> * define two classes C and D on top of the preceding class based on Chrono
> and DateTime

That's pretty much what I'd suggested. Only I was thinking of free
functions found via ADL or type traits instead of C and D. Thinking
more about it, ADL will probably fail with compilers with two-phase
name lookup (gcc), so this leaves us the type traits solution.

> The main problem is that the interface of the base class will need to be
> modified for OS that support better precession than nanosecond. This is what
> Chrono tried to avoid. Any way if the base_ class is non-public this is a
> minor issue. In fact the current implementation works a little bit like
> that?

I think B could be made so that it stores OS-dependent precision
internally, so no conversion is required in addition to conversion
from Chrono or DateTime. This means that B's precision is not
consistent across different platforms, but that is ok if it's not
public.

> The current class boost::XXX could be the C class as it follows the
> standard. The base class could be called boost::base_XXX and the DateTime
> bases interface could be moved to a specific DATE_TIME namespace
> boost::DATE_TIME::XXX or named boost::DATE_TIME_XXX.

I didn't quite understand that. I was thinking of the following layout:

1. Boost.Thread provides a separate header that contains forward
declaration of type traits for plugging in a time library. It contains
no includes and may look like this:

  namespace boost {
    template< typename TimeT, typename = void >
    struct thread_time_traits;
  }

The second template parameter is for SFINAE-based specializations
resolution, like it is done in Phoenix.

2. Boost.Thread provides another header that defines a
thread_time_traits specialization for std::chrono. This header is not
included anywhere, users are required to include it themselves if they
want to use std::chrono with Boost.Thread.
3. Boost.DateTime and Boost.Chrono define their own specializations of
this template. These specializations are included automatically by
respective Boost.DateTime and Boost.Chrono headers that define time
units. This will make these libraries automatically supported by
Boost.Thread.
4. Boost.Thread never includes Boost.DateTime or Boost.Chrono, all
time units are accepted as templated types by Boost.Thread methods.
thread_time_traits template is used to convert Boost.DateTime and
Boost.Chrono units to B (Boost.Thread's internal time representation).

This is just a general idea. I realize that Boost.Thread accepts both
time points and durations, and thread_time_traits would have to be
specialized for both. That's the reason I left the second template
parameter to be able to specialize the trait once for all types the
time library provides. There are other ways, like first determine the
library the time unit belongs to (this can be represented by a tag
type) and then specialize the trait on that tag, but that involves
more templates and would affect compile performance more.

> Is this close to what you are looking for/proposing? Would you agree to be
> forced to change the name of the class that still provide the DateTime based
> interface and the file that includes it?

With reservations I made above this looks quite close. I do not
propose to change the public interface of DateTime or Chrono. Thread
public interface would also remain intact unless users rely on public
method signatures (which is a bad idea anyway). No files have to be
renamed.

> Is it worth doing all these changes just to avoid the dependency on
> Boost.Chrono?

Yes, I think it is.