Re: [boost] [date-time][threads] Integrating C++0x clocks, time points, and durations into Boost?

From: Jeff Garland (azswdude_at_[hidden])
Date: 2008-06-18 10:48:46

On Wed, Jun 18, 2008 at 5:42 AM, Howard Hinnant <hinnant_at_[hidden]>
wrote:

> On Jun 18, 2008, at 7:03 AM, Paul A Bristow wrote:
>
>
>>
>>  -----Original Message-----
>>> From: boost-bounces_at_[hidden]
>>> [mailto:boost-bounces_at_[hidden]] On Behalf Of Beman Dawes
>>> Sent: 17 June 2008 12:41
>>> To: Boost Developers Mailing List
>>> Subject: [boost] [date-time][threads] Integrating C++0x
>>> clocks, time points, and durations into Boost?
>>>
>>> A slightly updated version of
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2615.html was
>>> accepted at the C++ committee meeting last week. It provides clocks,
>>> time points, and time durations for the C++0x standard library, and
>>> slightly modifies the threads interface already voted into
>>> C++0x to use these features.
>>>
>>
>>  Although these clock and time features evolved from Boost
>>> Date-Time, the
>>> actual realization is quite different. So we've got a transition that
>>> has to be managed. I'd personally like to see that transition occur
>>> quickly, both because Boost.Threads depends on these features, and
>>> because I can now bring forward an improved Boost.Timer based on these
>>> features.
>>>
>>

I agree, I'd like to see this happen rather quickly -- because of the
differences you cite I have to rework the TR2 proposal and I'd like to
understand all the details of how that will be achieved.  At the same time I
think we need to look at maintaining some backward compatibility with the
Boost date-time types so those users don't necessarily need to rewrite code.

> Even a cursory glance at (the convincing) N2615 makes it clear to me that
>> standardizing something as fundamentally important as this
>> without an implementation exposed to very many eyes and brains and
>> real-life 'use in anger' is asking for trouble.
>>
>
Be assured, the proposal really isn't as different as Beman's mail makes it
seem.  The duration types operate almost exactly the same as the current
boost date-time types from a user perspective.  The main exceptions being
that they have no special values and no i/o features.  They are implemented
in a fashion that is better than the current duration types which gives them
some conversion abilities that the current Boost date-time types don't have
-- in particular, you have a well documented duration template that you can
use to create your own types. As for the thread part of the API it is very
much similar to the ASIO interfaces and the 1.35 threading interfaces.

>
>> So I agree that a Top Priority is to get a Boost implementation into use
>> asap.
>>
>> (But I have no expertise or suggestions on how to achieve this).
>>
>> Sadly, the timing is wrong to get some GSoC manpower on this.
>>
>
> A public example implementation exists for this proposal (with only a few
> minor details wrong such as it is using the wrong nested namespace).
>  However I'm hesitant to point people at it.  It is a good test of the
> wording to have an independent implementation.  That will expose ambiguities
> in the normative wording that otherwise may be covered up.  I'd love to see
> a boost implementation as well.

As I said above we have some boost specific concerns that we may need to
address in our implementation.  I think I'll want to put the new stuff in a
new namespace -- do we have anything for 0x yet?  Maybe boost::cpp0x or
boost::cpp0x::date_time?

> Jeff's on the beach this week (literally). :-)
>

Quite true -- I can see the sand from where I type  -- and feel the soreness
from 3 hours in the surf with the kids yesterday ;-)

Jeff