On Wed, Jun 18, 2008 at 5:42 AM, Howard Hinnant <hinnant@twcny.rr.com> wrote:
On Jun 18, 2008, at 7:03 AM, Paul A Bristow wrote:
-----Original Message-----
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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