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.

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.

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. Jeff's on the beach this week (literally). :-) -Howard

Jeff Garland wrote:

...

...

...

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.

OK, let's work to make it all happen. See below for possibilities.

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.

Agreed.

...

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?

One thing that came out of the LWG's discussion of N2615 was a strong (10 for, 0 against) preference for putting the clock/duration/time_point stuff in a sub-namespace. While the LWG reserves the right to make future sub-namespace decisions on a case-by-case basis, there was strong support for sub-namespaces for specific problem domains, particularly those with a lot of very common names inside. Perhaps that can guide your choices. Hum... I think we should follow the Boost TR1 practice, which provides the actual declarations and definitions in a boost:: sub-namespace, and then provides a <boost/tr1/whatever> header that hoists the names into namespace std::tr1 with usings. So in this case, we would provide a <boost/cpp0x/chrono> header with names in namespace std::chrono. The names would be hoisted into that namespace via usings from a boost namespace such as your suggested boost::cpp0x::date_time or boost::date_time::cpp0x or boost::date_time::chrono or whatever. How does that sound? Perhaps all of us working on C++0x stuff could work on a common branch, say branches/cpp0x.

...

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 ;-)

Ah! The good life! --Beman

Jeff Garland wrote:

On Wed, Jun 18, 2008 at 2:30 PM, Beman Dawes <bdawes@acm.org> wrote:

...

... Perhaps all of us working on C++0x stuff could work on a common branch, say branches/cpp0x.

Do we need a branch? Since much of the initial stuff is additions I think a big chunk can just go on the main branch -- I'm just worried it will be hard to get tests if we go to a branch.

Some of the C++0x config stuff I'm working on requires changes to boost/config headers that will force recompiles of much of Boost. Thus I don't want to merge that into the trunk until it is known good and has been looked at by others. The N2661 additions require changes to Boost type traits, date-time, threads, and whatever library ratio goes into. It seems like the best way to coordinate that is for the developers working on those components to work on a branch. C++0x is no longer something off in the far distant future. The committee's plan is to ship a feature complete (including Concepts) draft of the standard after the September meeting. GCC, Borland, and Intel have shipped (GCC) or are in beta with compilers supporting important C++0x features such as rvalue references. Other compiler suppliers are known to be actively working on C++ features for their next releases. --Beman

vicente.botet wrote:

Hi,

----- Original Message ----- From: "Beman Dawes" <bdawes@acm.org>

...

Hum... I think we should follow the Boost TR1 practice, which provides the actual declarations and definitions in a boost:: sub-namespace, and then provides a <boost/tr1/whatever> header that hoists the names into namespace std::tr1 with usings.

This is valid for an existing boost library that is later accepted for the TR1, but not for a library that is accepted for the TR1 and need an implementation in boost.

...

So in this case, we would provide a <boost/cpp0x/chrono> header with names in namespace std::chrono. The names would be hoisted into that namespace via usings from a boost namespace such as your suggested boost::cpp0x::date_time or boost::date_time::cpp0x or boost::date_time::chrono or whatever.

How does that sound?

I don't understand. boost::tr1is already used for all the TR1 additions of c++0x? So why not place all these files directly on the boost/tr1 directory with namespace std::tr1 or a more specific one?

Am I missed some thing?

Yes:-) These additions are pure C++0x components and are not part of any TR. They are going directly into the standard. Incidentally, TR1 is long since complete and will never be changed. Any new library components not put directly into the standard during this revision cycle will go into TR2, a new technical report. --Beman

Anthony Williams wrote:

Beman Dawes <bdawes@acm.org> writes:

...

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.

...

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.

One suggestion is for Boost to provide an implementation of the headers to be added to C++0x, and then to use those headers in the various Boost libraries that need them. But I haven't thought it out in any detail.

I think it would be really useful to have an implementation of this in boost. I've always intended Boost.Thread to track the standard, so I will be making these changes in due course.

Good! Let's coordinate to avoid duplication of effort.

I think the point Ion made about backwards compatibility in Boost.Thread is important, so I will retain the old function names and signatures as well, at least for a couple of releases.

Yes, that's a help for users. --Beman

2008/6/18 Beman Dawes <bdawes@acm.org>:

Beman Dawes wrote:

...

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.

...

<snip>

...

I've emailed Howard to see if his prototype implementation can be made available with the Boost license. The answer was yes, but he points out that an independent implementation would be better in terms of flushing out issues with the proposed text for the standard.

The proposal has several components:

<snip>

* ratio: "ratio is a general purpose utility inspired by Walter Brown allowing one to easily and safely compute rational values at compile time." The proposal puts this in the Utilities chapter of the standard library. It has a lot of similarity to type traits.

I thought this bit looked simple enough to have a go at, so I took a shot at it and am attaching the results (tested with gcc 4.2.3 on Ubuntu). My conclusion is that the (relevant bit of) text is as clear as it needs to be - since I could follow it - except for one point: When it says: """ num shall have the value sign(N)*sign(D)*abs(N)/gcd. den shall have the value abs(D)/gcd. """ ... are sign() and abs() supposed to be runtime functions? I implemented them as meta-functions - I'm sure these are in boost somewhere, I just don't know where. Maybe compilers are generally clever enough, or the standard guarantees those functions will be evaluated at compile time? I'm never sure where the line is drawn on this one... The attached code is quite straightforward and basically does what the text says it should (I hope), but no more. The main limitation is that it uses static_gcd<> from Boost.Math. That meta-function is parametrised with `unsigned long` instead of `intmax_t` which limits how big the allowed numbers can be. I tried without luck to change the relevant header but I suppose it's not really relevant to this experiment. One other thing that threw me: """ The proposal is entirely an add-on. It will break no existing C++03 code, subject to the usual caveat that user code giving a using namespace std may see name clashes. Even that possibility is mitigated because the time portion of the proposal is in a std sub-namespace. """ I had no idea that it was a given that `using namespace std` could cause name clashes... Oh well, good thing I don't do that. :) Anyway, I hope Boost gets a high-resolution timer quick-sharp; it's long overdue imho. Kind regards, Darren

Thanks for doing this Darren. A few comments below... On Jun 18, 2008, at 11:48 PM, Darren Garvey wrote:

I thought this bit looked simple enough to have a go at, so I took a shot at it and am attaching the results (tested with gcc 4.2.3 on Ubuntu). My conclusion is that the (relevant bit of) text is as clear as it needs to be - since I could follow it - except for one point:

When it says: """ num shall have the value sign(N)*sign(D)*abs(N)/gcd.

den shall have the value abs(D)/gcd.

"""

... are sign() and abs() supposed to be runtime functions? I implemented them as meta-functions - I'm sure these are in boost somewhere, I just don't know where. Maybe compilers are generally clever enough, or the standard guarantees those functions will be evaluated at compile time? I'm never sure where the line is drawn on this one...

They have to execute at compile time. Whether or not the C++0X constexpr feature can be brought to bear here I really don't know. In my example implementation they were simply "__"-prefixed meta functions.

The attached code is quite straightforward and basically does what the text says it should (I hope), but no more. The main limitation is that it uses static_gcd<> from Boost.Math. That meta-function is parametrised with `unsigned long` instead of `intmax_t` which limits how big the allowed numbers can be. I tried without luck to change the relevant header but I suppose it's not really relevant to this experiment.

This is a show-stopper. One of the basic features of ratio is that you can throw any integral value at it, and it will either hand back the right answer or refuse to compile. Some worrisome results: typedef boost::utility::ratio<1, 0x8000000000000000LL> R9; std::cout << R9::num << '/' << R9::den << '\n'; -1/-9223372036854775808 This paragraph:

A diagnostic shall be emitted if ratio is instantiated with D == 0, or if the absolute value of N or D can not be represented. [Note: These rules ensure that infinite ratios are avoided and that for any negative input, there exists a representable value of its absolute value which is positive. In a two's complement representation, this excludes the most negative value. -- end note]

was intended to cause the above example to fail to compile because abs(0x8000000000000000) < 0. Once we have an intmax_t-based gcd, the ratio arithmetic and less-than comparison will need more work to detect overflow and subsequently refuse to compile:

For each of the class templates in this clause, each template parameter shall refer to a ratio. If the implementation is unable to form the indicatedratio due to overflow, a diagnostic shall be issued.

...

If R1::num * R2::den < R2::num * R1::den, ratio_less derives from true_type, else derives from false_type. Implementations are permitted to use more complex algorithms to compute the above relationship to avoid overflow. If the implementation is not able to avoid overflow, a diagnostic shall be emitted.

In general, N2615 is sprinkled liberally with "diagnostic required". Errors which can be detected at compile time are actively sought out. -Howard