c++0x std::ratio implementation

Updated patch.

Thanks. I'm looking into it. Note that, currently at least, we cannot assume <cstdintto be non-trivial on all the platforms supported by GCC, that is, std::intmax_t may well be unavailable. The code and the tests require guards

Paolo.

Hi,

With something like __GLIBCXX_HAS_STDINT_H? , even if stdint.h
is
defined, its still not guaranteed to have intmax_t? But if it
doesn't,
won't including cstdint give a compiler error (due to "using
::intmax_t)?

Can we assume that if INTMAX_MAX is defined, then intmax_t is
available?

We already have _GLIBCXX_USE_C99_STDINT_TR1, we have only to use it, consistently, to wrap both code using <cstdint(the header itself can be included unconditionally) and the corresponding testcases.

If you can do that, + the small stylistic changes and resubmit we can commit very soon

Paolo.

Hi,

Attached is a patch that short-cuts ratio_less when denominators
are equal or signs differ. This prevents overflow in a few cases
(test case provided).




Also, I added some doxygen documentation to std::ratio class.
However, when I built the documentation (html) it didn't look like it
was picking up the header. Does something need modification for
doxygen to pick it up.

Let's ask Benjamin

I'm committing the below, which avoids in <ratiothe use of the various limit macros, which, according to C99, in C++ are not defined in <stdint.hwhen __STDC_LIMIT_MACRS is not defined. In fact we have a problem here, because, in C++0x, the availability of those limit macros in <cstdintis supposed to be *independent* of the feature macro to be defined and since our <cstdintincludes <stdint.hit suffices that the user includes once the latter without defining the feature macro for the following inclusion of <cstdintto become a NP, thus the limit macros remain forever unavailable grunt. In fact this requirement in C++0x seems to me largely contrary to the resolution of DR 456, I have to study the issue a little more