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