Boost logo

Boost :

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
>we have:
> 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
>go away.

Let's hope so!


Boost list run by bdawes at, gregod at, cpdaniel at, john at