By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,946 Members | 697 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,946 IT Pros & Developers. It's quick & easy.

64 bit integers etc...

P: n/a
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.

Aug 15 '07 #1
Share this Question
Share on Google+
10 Replies


P: n/a
Hi!

SpreadTooThin schrieb:
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
Aug 15 '07 #2

P: n/a

SpreadTooThin <bj********@gmail.comwrote in message...
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 <limitsin 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.

--
Bob R
POVrookie
Aug 15 '07 #3

P: n/a
On Aug 15, 9:56 am, SpreadTooThin <bjobrie...@gmail.comwrote:
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
Aug 15 '07 #4

P: n/a
to***********@yahoo.co.uk wrote:
:: On Aug 15, 9:56 am, SpreadTooThin <bjobrie...@gmail.comwrote:
::: 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

Aug 15 '07 #5

P: n/a
>
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?

Tony

Aug 15 '07 #6

P: n/a

SpreadTooThin <bj********@gmail.comwrote in message...

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?
Tony
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();
}
}

--
Bob R
POVrookie
Aug 15 '07 #7

P: n/a
Hi!

BobR schrieb:
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
Aug 15 '07 #8

P: n/a
On Aug 16, 12:50 am, SpreadTooThin <bjobrie...@gmail.comwrote:
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

Aug 17 '07 #9

P: n/a
On Aug 16, 11:16 pm, tony_in_da...@yahoo.co.uk wrote:
On Aug 16, 12:50 am, SpreadTooThin <bjobrie...@gmail.comwrote:
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.
Cheers,

Tony

Aug 17 '07 #10

P: n/a
On Aug 18, 12:45 am, SpreadTooThin <bjobrie...@gmail.comwrote:
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

Aug 19 '07 #11

This discussion thread is closed

Replies have been disabled for this discussion.