From: Beman Dawes (beman_at_[hidden])
Date: 2000-09-25 07:14:50
John Maddock wrote:
>I have a couple of further minor comments:
>Shouldn't the int_fastX_t's be at least int sized? For example currently
> typedef signed char int_fast8_t;
>but shouldn't that be:
> typedef int int_fast8_t;
>assuming that int is the fastest type?
Yes, although that is making an performance assumption which is very
dependent on CPU architecture. It might not be optimal for many 8-bit
processors, for example. Never the less, I've made these changes:
typedef int int_fast8_t; // assume int faster than char
typedef unsigned int uint_fast8_t; // assume int faster than char
typedef int int_fast16_t; // assume int faster than
typedef unsigned int uint_fast16_t; // assume int faster than
>Also I assume that for portable code we probably shouldn't use fixed
>integer types at all - where as the int_leastXX_t and int_fastXX_t types
>are guarenteed to always be available, the inXX_t types are not.
Yes, that's correct. I find myself writing int32_t because int_least32_t
is longer and uglier.
For boost, it might be worthwhile to periodically grep for the intXX_t
forms to make sure they aren't creeping in. I just did that (on the MAIN
branch), and the only place they currently appear is in random library.
>Finally, I tracked down the problem that cygwin was having - the header
>"LL" appended to the end of LONG_LONG_MAX which throws the preprossor -
>this is not a legal definition as these should be declared in a way that
>are usable for preprocessing declarations. Mingw32 has even more of
>problems BTW. Hopefully when libstdc++3 arrives these problems should
Let's hope so!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk