64 bit integers etc...

[SpreadTooThin]

I am used to coding by defining my own integer data types. For
example:

u8bit is unsigned char
u16bit is unsigned short
u32bit is unsigned long or int

With the introduction of 64 bit architectures I'm curious as to what
one should use for 64 bit integers.

I've been codeing on Macs for a while now and I've noticed some
datatypes like __64bitint__
(Don't remember exactly)

XCode I believe is calling g++ compiler.
What does the c++ standard say or recommend that one uses for larger
integer datatypes..
I'm worried that some were I've defined a int and was expecting a 16
or 32 bit I may actually be getting (eventually) a 64 bit.
I want my code to be very specific about the size of the integers it
is declaring.

 

[Frank Birbacher]

Hi!

What does the c++ standard say or recommend that one uses for larger
integer datatypes..

In Standard C++ "long" ist the biggest type. Might change in future.

I want my code to be very specific about the size of the integers it
is declaring.

Maybe that helps: a portable header for integer types of specific width.

http://www.boost.org/libs/integer/integer.htm

Frank

 

[Alf P. Steinbach]

* SpreadTooThin:

I am used to coding by defining my own integer data types. For
example:

u8bit is unsigned char
u16bit is unsigned short
u32bit is unsigned long or int

With the introduction of 64 bit architectures I'm curious as to what
one should use for 64 bit integers.

I've been codeing on Macs for a while now and I've noticed some
datatypes like __64bitint__
(Don't remember exactly)

XCode I believe is calling g++ compiler.
What does the c++ standard say or recommend that one uses for larger
integer datatypes..
I'm worried that some were I've defined a int and was expecting a 16
or 32 bit I may actually be getting (eventually) a 64 bit.
I want my code to be very specific about the size of the integers it
is declaring.

As I understand it future standard will be "long long int" (i.e. just
"long long") as the built-in type that guarantees at least 64 bits.

Anyways, in order of ideally best-first, contradicting my own advice of
not many days ago (but hey, this time I thought about it for a few
seconds before rushing to type a response!, also, benefit of responses
to that response, hindsight is a great tool):

1. Use <stdint.h> if available.
2. Typedef u64bit as whatever your compiler offers.
3. Roll-your-own as a C++ class.

 

[BobR]

I am used to coding by defining my own integer data types. For
example:

u8bit is unsigned char
u16bit is unsigned short
u32bit is unsigned long or int

With the introduction of 64 bit architectures I'm curious as to what
one should use for 64 bit integers.

I've been codeing on Macs for a while now and I've noticed some
datatypes like __64bitint__
(Don't remember exactly)

XCode I believe is calling g++ compiler.
What does the c++ standard say or recommend that one uses for larger
integer datatypes..
I'm worried that some were I've defined a int and was expecting a 16
or 32 bit I may actually be getting (eventually) a 64 bit.
I want my code to be very specific about the size of the integers it
is declaring.

You might find some information by looking through <limits> in your
implementation.

Try ( in main() ):
std::cout <<(std::numeric_limits<long long>::digits)<<std::endl;

If it compiles, you know you have type 'long long'. Check it's bit size.

 

[tony_in_da_uk]

I am used to coding by defining my own integer data types.

For what it's worth - which might not be much - except in specific
situations where the binary format of data, or the space taken by
large containers is critical, there's rarely a good reason to specify
exact widths. It simply suggests to anyone seeing your code that you
have not understood the reasons for the types not being set-width in
the first place - doesn't make a good impression :-<.

I'm worried that some were I've defined a int and was expecting a 16
or 32 bit I may actually be getting (eventually) a 64 bit.
I want my code to be very specific about the size of the integers it
is declaring.

So, why? ;-) What would be the consequences of getting 64 bit values
that worry you?

Tony

 

[Bo Persson]

(e-mail address removed) wrote:
::: I am used to coding by defining my own integer data types.
::
:: For what it's worth - which might not be much - except in specific
:: situations where the binary format of data, or the space taken by
:: large containers is critical, there's rarely a good reason to
:: specify exact widths. It simply suggests to anyone seeing your
:: code that you have not understood the reasons for the types not
:: being set-width in the first place - doesn't make a good
:: impression :-<.
::
::: I'm worried that some were I've defined a int and was expecting a
::: 16 or 32 bit I may actually be getting (eventually) a 64 bit.
::: I want my code to be very specific about the size of the integers
::: it is declaring.
::
:: So, why? ;-) What would be the consequences of getting 64 bit
:: values that worry you?

Or a 36 bit int?


Bo Persson

 

[SpreadTooThin]

So, why? ;-) What would be the consequences of getting 64 bit values
that worry you?

Well if you are writing to a spec that says that this portion of the
data stream is 32 bits long...
writing out sizeof(int) (or whatever) may not be the size you think it
should be?
Does that make sence?

 

[BobR]

Well if you are writing to a spec that says that this portion of the
data stream is 32 bits long...
writing out sizeof(int) (or whatever) may not be the size you think it
should be?
Does that make sence?

No, it doesn't make sense either. <G>

{
if( std::numeric_limits<unsigned long>::digits != 32 ){ /* <limits> */
std::cout<<"ERROR! aborting program"<<std::endl;
std::terminate();
}
}

 

[Frank Birbacher]

Hi!

No, it doesn't make sense either. <G>

{
if( std::numeric_limits<unsigned long>::digits != 32 ){ /* <limits> */
std::cout<<"ERROR! aborting program"<<std::endl;
std::terminate();
}
}

Time for a static assert, isn't it?

Frank

 

[tony_in_da_uk]

Well if you are writing to a spec that says that this portion of the
data stream is 32 bits long...
writing out sizeof(int) (or whatever) may not be the size you think it
should be?
Does that make sence?

Yes. It's the case I mentioned above "situations where the binary
format of data [...] is critical". Just that my impression from your
original post (rightly or wrongly) was that this was your preference,
and in my experience - even when working with fixed-size data - the
program will have a lot of other variables coordinating the work on
the fixed width data that shouldn't themselves be fixed in size (in
this way)...

Anyway, basically just offering to explain the non-deterministic sizes
of ints if it was something you weren't comfortable with. Not sure of
your experience level - sorry.

Cheers,

Tony

 

[SpreadTooThin]

Well if you are writing to a spec that says that this portion of the
data stream is 32 bits long...
writing out sizeof(int) (or whatever) may not be the size you think it
should be?
Does that make sence?

Yes. It's the case I mentioned above "situations where the binary
format of data [...] is critical". Just that my impression from your
original post (rightly or wrongly) was that this was your preference,
and in my experience - even when working with fixed-size data - the
program will have a lot of other variables coordinating the work on
the fixed width data that shouldn't themselves be fixed in size (in
this way)...

Anyway, basically just offering to explain the non-deterministic sizes
of ints if it was something you weren't comfortable with. Not sure of
your experience level - sorry.

hmmm... 25 years of Fortran, assembler, C and C++ etc etc etc....
I guess thats my point eh.. non-deterministic can be a problem for
some.
Being specific help make software work the way it was thought out.

 

[tony_in_da_uk]

hmmm... 25 years of Fortran, assembler, C and C++ etc etc etc....
I guess thats my point eh.. non-deterministic [int sizes] can be a problem for
some.
Being specific help make software work the way it was thought out.

There are a lot of us (circa quarter-century folks) and very few with
the insights or abilities of people like Koenig and Stroustrup.
Things are the way they are (in terms of sizes not being fixed) for
excellent reason: to allow programs written for older machines to
continue to work well on newer ones. It's an old issue, and given
your experience level, I'll leave you to it....

Cheers,

Tony