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-DateTi... Sent from the Boost - Dev mailing list archive at Nabble.com.