From: Darren Garvey (darren.garvey_at_[hidden])
Date: 2008-06-20 16:35:14
[sorry for sending this twice 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
>> know where. Maybe compilers are generally clever enough, or the standard
>> guarantees those functions will be evaluated at compile time? I'm never
>> 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
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';
> This paragraph:
> 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
> 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
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
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,
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk