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

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

> See header <inttypes.h>
>

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

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

On Jun 27, 4:57pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
> 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 <cinttypes> header 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 <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>.

Greg

> 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>.
>
> 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.

Greg Herlihy schrieb:
> On Jun 27, 4:57 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
>> 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 <cinttypes> header 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 <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>.
>
> Greg
>
>

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

cheers, chris

On Jun 27, 11:39 pm, joseph cook <joec...@gmail.com> 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?

As Victor said, you include <stdint.h>. Or if portability is a
concern, <stdint.hh>, or <stdint.hpp>, or <mystdint.hh> or
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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jun 28, 4:19 am, joseph cook <joec...@gmail.com> wrote:
> > 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:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On 2008-06-28 09:02, Chris Forone wrote:
> Greg Herlihy schrieb:
>> On Jun 27, 4:57 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
>>> 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 <cinttypes> header 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 <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>.
>>
>> Greg
>>
>>
>
> cant include with #include <cstdint>, #include <stdint.h> works. 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

Erik Wikström schrieb:
> On 2008-06-28 09:02, Chris Forone wrote:
>> Greg Herlihy schrieb:
>>> On Jun 27, 4:57 pm, Victor Bazarov <v.Abaza...@comAcast.net> wrote:
>>>> 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 <cinttypes> header 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 <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>.
>>>
>>> Greg
>>>
>>>
>> cant include with #include <cstdint>, #include <stdint.h> works. 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