Boost logo

Boost :

Subject: Re: [boost] [thread] Integration with Chrono and DateTime
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-10-16 18:24:05

Le 16/10/12 08:35, Andrey Semashev a écrit :
> On Sat, Oct 13, 2012 at 10:21 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>> on Fri Oct 12 2012, "Vicente J. Botet Escriba" <> wrote:
>>>>> Any addition code has its influence on how the library could evolve. I
>>>> really would prefer to remove these interfaces for Boost 1.56. I think that
>>>> 1 year and a half is enough time to move to the new interface.
>>>> Then I think library decoupling is the right way even more.
>>> You are surely right, but this is not a priority for me. What others think?
>> In general I'm all for decoupling, but in the case of Chrono I wonder if
>> it's worth the trouble, since it is, after all, standard in C++11.
>> Also, I bet C++03 implementations are going to start shipping with
>> approximations for all the C++11 libraries, if they haven't already.
> Decoupling has additional potential of reducing compile times.
> Currently, including boost/thread/mutex.hpp pulls in a great deal of
> DateTime and Chrono, even if you don't use any timed functions (which
> is a typical case).
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

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?

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.

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?
Is it worth doing all these changes just to avoid the dependency on


Boost list run by bdawes at, gregod at, cpdaniel at, john at