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

From: Darren Garvey (darren.garvey_at_[hidden])
Date: 2008-06-20 16:35:14

[sorry for sending this twice Howard]

Hi Howard,

2008/6/19 Howard Hinnant <hinnant_at_[hidden]>:

> <nod> Thanks Daren!
>
> The boost email server seems really slow (dead?) today.  Here's the
> response I sent over 2 hours ago:
>
> Thanks for doing this Darren (sorry about misspelling your name).  A few
> comments below...

No problem. I'm getting emails through sporadically too.

On Jun 18, 2008, at 11:48 PM, Darren Garvey wrote:
>
>> ... 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.
>

Ok. I think in context it's perfectly clear then.

>  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.
>>
>
> 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.
>

I did actually get that impression from the text, although I have to admit I
miss-remembered one paragraph:

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.

Being really nit-picky: It makes no difference semantically, but I think the
second and third sentences could possibly do with being the other way around
(or thereabouts), since the third is more important than the second. Maybe
C++ was making my brain expect the optional features in a feature-list to
come after the non-optional ones? ;-)

> Some worrisome results:
>
>   typedef boost::utility::ratio<1, 0x8000000000000000LL> R9;
>   std::cout << R9::num << '/' << R9::den << '\n';
>
> -1/-9223372036854775808
>
> This paragraph:
>
>  <snip>
>>
>
> was intended to cause the above example to fail to compile because
> abs(0x8000000000000000) < 0.
>

I didn't know you could do that to check for overflow. I think I fixed it in
my experimental implementation, using BOOST_MPL_ASSERT_MSG for some spiffy
diagnostics.

> 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:
>

I've attached a version of static_gcd which uses intmax_t, although I can't
find the relevant bit of the Boost.Math test-suite to check it properly.

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

I think I've added the necessary diagnostics to the ratio class itself, but
not to any of the operators yet

<time passes>

Ok, I've attached a 7-zipped version that does have the operators. I'm in
unfamiliar territory here, so there's probably more that can be done to help
with compile-time efficiency and whatnot. It also still needs some more
tests on the checked_ops and the ratio operators but I've run out of time
for now (and I'm sure you have a proper test-suite somewhere ;-).

IIUC, I *think* that only leaves dealing with the conditionals related to
the optional convenience SI typedefs.

Hope that helps,

Darren