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

Subject: Re: [boost] [thread] Integration with Chrono and DateTime
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2012-10-17 10:57:33

Andrey Semashev-2 wrote
> On Wed, Oct 17, 2012 at 2:24 AM, Vicente J. Botet Escriba
> <

> vicente.botet@

> > 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.

yes, I was thinking also to use non-member functions, but this doesn't
conforms to the C++11 standard.

>> 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.

I agree, making it private, avoid a lot of issues.

>> 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.

I don't think this should be desirable, but lets see ...

> 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.

Could you show the interface the class B look like with this traits?

>> 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.

Please, let me know about any design issues you could have while doing this
refactoring.

Best,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/thread-Integration-with-Chrono-and-DateTime-was-release-1-52-Release-Notes-tp4637044p4637271.html
Sent from the Boost - Dev mailing list archive at Nabble.com.