Platform independent types

[joseph cook]

The recent discussion on PIMPL and opaque pointers made me think about
a construct I have seen commonly with respect to defining types on a
platform by platform basis. Unlike structs, obviously types needs to
be 'complete' in header files for ease of use.

What I mean is something like the following...
#ifdef PLATFORM1
typedef unsigned long unsigned64;
....
#elseif PLATFORM2
typedef unsigned long long unsigned64;
#endif

That way you can ensure that a given type is the same size,
independent of platform.

With all the vitriol against "#if", etc, does anyone have any other
methods for achieving the same sort of effect?

Thanks

[Victor Bazarov]

joseph cook wrote:

The recent discussion on PIMPL and opaque pointers made me think about
a construct I have seen commonly with respect to defining types on a
platform by platform basis. Unlike structs, obviously types needs to
be 'complete' in header files for ease of use.

What I mean is something like the following...
#ifdef PLATFORM1
typedef unsigned long unsigned64;
...
#elseif PLATFORM2
typedef unsigned long long unsigned64;
#endif

That way you can ensure that a given type is the same size,
independent of platform.

With all the vitriol against "#if", etc, does anyone have any other
methods for achieving the same sort of effect?

See header <inttypes.h>

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[joseph cook]

See header <inttypes.h>

But that's a C99 header, not a C++ Header, right?

[Victor Bazarov]

joseph cook wrote:

>See header <inttypes.h>

But that's a C99 header, not a C++ Header, right?

Most compilers already provide it. And it's part of C++0x specification.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Greg Herlihy]

On Jun 27, 4:57*pm, Victor Bazarov <[e-mail]:

joseph cook wrote:

See header <inttypes.h>

But that's a C99 header, not a C++ Header, right?

Most compilers already provide it. *And it's part of C++0x specification.

Technically, the C++ version of this header file will be named
<cinttypes>. However, the <cinttypesheader is probably not the best
choice to look for platform-independent type names - because it
defines macros with names like "SCNiFAST64" and "SCNo32" - names which
some may find a little cryptic.

Fortunately, C++09x will also include the header <cstdintwhich -
instead of macros - declares various typedefs with names like
"int32_t" and "uint_fast64_t" which, as types names, are probably a
little clearer than the names #defined in <cinttypes>.

Greg

[joseph cook]

Fortunately, C++09x will also include the header <cstdintwhich -
instead of macros - declares various typedefs with names like
"int32_t" and "uint_fast64_t" which, as types names, are probably a
little clearer than the names #defined in <cinttypes>.

Greg

Thanks! It's good to see that getting added to the standard. I guess
this is, as I expected, a valid use of #if's in C++ circa 2008, which
will soon be eliminated.

[Chris Forone]

Greg Herlihy schrieb:

On Jun 27, 4:57 pm, Victor Bazarov <[e-mail]:

>joseph cook wrote:

>>>See header <inttypes.h>
But that's a C99 header, not a C++ Header, right?

Most compilers already provide it. And it's part of C++0x specification.

Technically, the C++ version of this header file will be named
<cinttypes>. However, the <cinttypesheader is probably not the best
choice to look for platform-independent type names - because it
defines macros with names like "SCNiFAST64" and "SCNo32" - names which
some may find a little cryptic.

Fortunately, C++09x will also include the header <cstdintwhich -
instead of macros - declares various typedefs with names like
"int32_t" and "uint_fast64_t" which, as types names, are probably a
little clearer than the names #defined in <cinttypes>.

Greg

cant include with #include <cstdint>, #include <stdint.hworks. is this
compiler-dependent?

cheers, chris

[James Kanze]

On Jun 27, 11:39 pm, joseph cook <[e-mail]:

The recent discussion on PIMPL and opaque pointers made me
think about a construct I have seen commonly with respect to
defining types on a platform by platform basis. Unlike
structs, obviously types needs to be 'complete' in header
files for ease of use.

What I mean is something like the following...
#ifdef PLATFORM1
typedef unsigned long unsigned64;
...
#elseif PLATFORM2
typedef unsigned long long unsigned64;
#endif

That way you can ensure that a given type is the same size,
independent of platform.

With all the vitriol against "#if", etc, does anyone have any
other methods for achieving the same sort of effect?

As Victor said, you include <stdint.h>. Or if portability is a
concern, <stdint.hh>, or <stdint.hpp>, or <mystdint.hhor
whatever. A header file in a platform dependent directory,
selected by the -I (or /I) option when you compile.

In this case, the implementation of this header for most systems
is to just include <stdint.h>. If you do stumble on an
implementation which doesn't support it, however, you provide
the necessary code by hand.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jun 28, 4:19 am, joseph cook <[e-mail]:

Fortunately, C++09x will also include the header <cstdint>
which - instead of macros - declares various typedefs with
names like "int32_t" and "uint_fast64_t" which, as types
names, are probably a little clearer than the names #defined
in <cinttypes>.

Thanks! It's good to see that getting added to the standard.
I guess this is, as I expected, a valid use of #if's in C++
circa 2008, which will soon be eliminated.

No, it's not a valid use of #if's. I've used my own stdint.hh
for years now, with no #if's.

In any reasonable project, there's a directory per target
platform, for the platform specific stuff. You don't mix stuff
for different platforms in the same file; you choose which file
you include by means of a -I (or /I) option to the compiler.

There is one valid use of #if's: include guards, but that's the
only one I've ever really found.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-06-28 09:02, Chris Forone wrote:

Greg Herlihy schrieb:

>On Jun 27, 4:57 pm, Victor Bazarov <[e-mail]:

>>joseph cook wrote:
See header <inttypes.h>
But that's a C99 header, not a C++ Header, right?
Most compilers already provide it. And it's part of C++0x specification.

Technically, the C++ version of this header file will be named
<cinttypes>. However, the <cinttypesheader is probably not the best
choice to look for platform-independent type names - because it
defines macros with names like "SCNiFAST64" and "SCNo32" - names which
some may find a little cryptic.

Fortunately, C++09x will also include the header <cstdintwhich -
instead of macros - declares various typedefs with names like
"int32_t" and "uint_fast64_t" which, as types names, are probably a
little clearer than the names #defined in <cinttypes>.

Greg

cant include with #include <cstdint>, #include <stdint.hworks. is this
compiler-dependent?

As others have pointed out, currently there is no stdint in C++ (but it
will be in C++09, where it will be called <cstdint>), but you can use
the C version of the file <stdint.h>.

--
Erik Wikström

[Chris Forone]

Erik Wikström schrieb:

On 2008-06-28 09:02, Chris Forone wrote:

>Greg Herlihy schrieb:

>>On Jun 27, 4:57 pm, Victor Bazarov <[e-mail]:
joseph cook wrote:
>See header <inttypes.h>
But that's a C99 header, not a C++ Header, right?
Most compilers already provide it. And it's part of C++0x specification.
Technically, the C++ version of this header file will be named
<cinttypes>. However, the <cinttypesheader is probably not the best
choice to look for platform-independent type names - because it
defines macros with names like "SCNiFAST64" and "SCNo32" - names which
some may find a little cryptic.

Fortunately, C++09x will also include the header <cstdintwhich -
instead of macros - declares various typedefs with names like
"int32_t" and "uint_fast64_t" which, as types names, are probably a
little clearer than the names #defined in <cinttypes>.

Greg

cant include with #include <cstdint>, #include <stdint.hworks. is this
compiler-dependent?

As others have pointed out, currently there is no stdint in C++ (but it
will be in C++09, where it will be called <cstdint>), but you can use
the C version of the file <stdint.h>.

thanks! cheers, chris