[Insight-developers] Fixed width integer types, itkIntTypes, and portable 64-bit integer

[Brad King]

Tom Vercauteren wrote:
> From a purely aesthetic point of view, I have to say that
> kwsys::FundamentalType_IntXX looks a little long.
> 
> From a broader perspective, I also tend to like your third option
> because cstdint will become standard c++ (it is in TR1).
[snip]
Sean McBride wrote:
> My 2¢: I think using the stdint.h types is best.  After all, they are
> the standardized solution to this very problem!  And they are easier to
> type and read than something like kwsys::FundamentalType_IntXX.

FYI, the actual names of the KWSys types in ITK would be of the form:

  itksysFundamentalType_U?Int(8|16|32|64)

However, these were not meant for direct use.  They are meant as
try-compile results with out-of-the-way names that can be typedef'd
as needed.

The problem with <stdint.h> (or really <cstdint> for future C++) is that
providing compatibility with compilers that do not provide it must be done
carefully to avoid namespace violations.  I'm aware of several projects
that just typedef int32_t in the global namespace of public headers :(
We need a better solution.

I suggest that we define the same types that stdint.h defines, except
put them in the itk:: namespace.  We can use stdint.h where available
and fall back on KWSys FundamentalType to get the types elsewhere:

// Common/itkStdInt.h
#ifdef ITK_HAVE_STDINT_H
# include <stdint.h>
namespace itk {
  typedef ::int32_t int32_t; // OR using ::int32_t;
  typedef ::int64_t int64_t;
  ...
}
#else
# include <itksys/FundamentalType.h>
namespace itk {
  typedef ::itksysFundamentalType_Int32 int32_t;
  typedef ::itksysFundamentalType_Int64 int64_t;
  ...
}
#endif

This approach will work everywhere, avoids defining names outside the
"itk::" namespace, and allows ITK code to use the types without any
qualification.  When <cstdint> is standard in the future, we can switch
the definitions to

#include <cstdint>
namespace itk {
  using ::std::int32_t;
  using ::std::int64_t;
  ...
}

I think the same approach is already in use by the Boost community.

-Brad K