Re: [boost] stdint.h

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 
short
      typedef unsigned int    uint_fast16_t; // assume int faster than 
short

 >Also I assume that for portable code we probably shouldn't use fixed 
width
 >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 
has
 >"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 
these
 >problems BTW.  Hopefully when libstdc++3 arrives these problems should 
all
 >go away.

Let's hope so!

--Beman