[Insight-developers] Fixed width integer types, itkIntTypes, and portable 64-bit integer
Bill Lorensen
bill.lorensen at gmail.com
Mon Dec 7 12:00:27 EST 2009
Looks like a clean solution that is adaptable to the future.
On Mon, Dec 7, 2009 at 9:19 AM, Brad King <brad.king at kitware.com> wrote:
> 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
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>
More information about the Insight-developers
mailing list