Does your favorite C++ compiler support 64-bit integer types?
Matt
Some of the integer variables in my application will need to hold values
bigger than 2^32-1.
Others won't need to be that big. Time and space efficiencies on
run-of-the-mill (read: 32 bit) microcomputers are important.
I want to use some layer of abstraction comparable to C99's stdint.h so
that my variable declarations specify the number of bits.
My app is to run on general-purpose hardware on Linux, Mac, BSD, and
Windows.
I am more interested in practical portability than in ISO standards.
Also it seems to be irrelevant whether the 64-bit type is long or long long.
Which C++ compilers do and which do not have 64-bit integer types? And
do they have something like stdint.h?
David Harmon
<ma...@themattfella.zzzz.com> wrote,
>Which C++ compilers do and which do not have 64-bit integer types? And
>do they have something like stdint.h?
Digital Mars C++ http://www.digitalmars.com
has "long long" and stdint.h.
John Carson
news:cPYec.1041$ei3...@news02.roc.ny
Microsofts has a 64 bit data type, though I think it is less efficient than
the 32 bit integer type. The various types (besides the usual int etc.) are
listed here.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/win64/win64/the_new_data_types.asp
--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)
Matt
And its long long is 64 bits?
Ioannis Vranos
> Please skip to the last paragraph if you are in a hurry.
>
> Some of the integer variables in my application will need to hold values
> bigger than 2^32-1.
>
> Others won't need to be that big. Time and space efficiencies on
> run-of-the-mill (read: 32 bit) microcomputers are important.
>
> I want to use some layer of abstraction comparable to C99's stdint.h so
> that my variable declarations specify the number of bits.
You can easily define your own class. I also assume that there must be some
third party free library out there provoding an 64-bit type.
Or you can use a system-specific type like __int64 in .NET.
> My app is to run on general-purpose hardware on Linux, Mac, BSD, and
> Windows.
>
> I am more interested in practical portability than in ISO standards.
> Also it seems to be irrelevant whether the 64-bit type is long or long
long.
There isn't long long in standard C++. Portability can be maintained by
using a typedef for built in system-specific types. For example you could
do:
typedef __int 64 Int64
// ...
and change the typedef when you move to another system. The general rule is
"isolate system dependencies in a small portion of the code". You can create
a header file called
system_dependencies.h or something.
>
> Which C++ compilers do and which do not have 64-bit integer types? And
> do they have something like stdint.h?
How many compilers exist out there? How many versions of them? The question
is meaningless. You can basically tell us what OS you are using. For Windows
a nice free port of GCC supporting Win32 API is mingw:
If you want it integrated with an IDE you can download Dev-C++:
http://www.bloodshed.net/devcpp.html
Ioannis Vranos
Chuck McDevitt
long long is supported and is the same as __int64.
David Harmon
<ma...@themattfella.zzzz.com> wrote,
>David Harmon wrote:
>> On Tue, 13 Apr 2004 21:19:04 GMT in comp.lang.c++, Matt
>> <ma...@themattfella.zzzz.com> wrote,
>>
>>>Which C++ compilers do and which do not have 64-bit integer types? And
>>>do they have something like stdint.h?
>>
>>
>> Digital Mars C++ http://www.digitalmars.com
>> has "long long" and stdint.h.
>>
>
>And its long long is 64 bits?
Yes. I thought I implied that. It would certainly violate expectations
if it was anything less.
Using free command line DMC++ with accompanying stlport library.
Program:
#include <iostream>
int main()
{
int j = 0;
long long int i = 0;
do {
i = (i << 1) + 1;
++j;
std::cout << j << " " << i << '\n';
} while (i > 0);
}
Output:
1 1
2 3
3 7
4 15
5 31
6 63
7 127
8 255
9 511
10 1023
11 2047
12 4095
13 8191
14 16383
15 32767
16 65535
17 131071
18 262143
19 524287
20 1048575
21 2097151
22 4194303
23 8388607
24 16777215
25 33554431
26 67108863
27 134217727
28 268435455
29 536870911
30 1073741823
31 2147483647
32 4294967295
33 8589934591
34 17179869183
35 34359738367
36 68719476735
37 137438953471
38 274877906943
39 549755813887
40 1099511627775
41 2199023255551
42 4398046511103
43 8796093022207
44 17592186044415
45 35184372088831
46 70368744177663
47 140737488355327
48 281474976710655
49 562949953421311
50 1125899906842623
51 2251799813685247
52 4503599627370495
53 9007199254740991
54 18014398509481983
55 36028797018963967
56 72057594037927935
57 144115188075855871
58 288230376151711743
59 576460752303423487
60 1152921504606846975
61 2305843009213693951
62 4611686018427387903
63 9223372036854775807
64 -1
David Harmon
The following numbers (in the second column) all end with the digit
1, 3, 5, or 7. It's obvious why they are all odd. Why can the last
digit never be 9, even if you extended the sequence?
On Tue, 13 Apr 2004 22:57:45 GMT in comp.lang.c++, David Harmon
<sou...@netcom.com> wrote,
John Carson
news:40c87c9a....@news.west.earthlink.net
> Here is a brain teaser for anyone who might be interested.
> The following numbers (in the second column) all end with the digit
> 1, 3, 5, or 7. It's obvious why they are all odd. Why can the last
> digit never be 9, even if you extended the sequence?
i = (i << 1) + 1;
translates to
i = i*2 +1;
This is a first order difference equation with solution (given the initial
condition)
i_n = 2^n - 1
where i_n is the nth term in the sequence and ^ denotes exponent.
(Alternatively, you are forming each successive number by left-shifting and
adding 1, which means that you have a binary number consisting solely of 1s.
Such numbers are of the form 2^n - 1.)
For a number to end in 9, we would need:
2^n - 1 == K*10 + 9
for some integers n and K. Adding 1 to both sides
2^n == K*10 + 10
or
2^n == (K+1)*10
Dividing both sides by 2:
2^(n-1) == (K+1)*5
We see that the left hand side has 2 as its only prime factor, whereas the
right hand side has 5 as a prime factor. By the unique prime factorisation
theorem, this is impossible if the left and right hand sides are equal. This
shows the equality is impossible. QED.
Matt
> Here is a brain teaser for anyone who might be interested.
> The following numbers (in the second column) all end with the digit
> 1, 3, 5, or 7. It's obvious why they are all odd. Why can the last
> digit never be 9, even if you extended the sequence?
It would imply that some power of two is divisible by five.
David Harmon
<donald...@datafast.net.au> wrote,
...
>By the unique prime factorisation theorem, this is
>impossible if the left and right hand sides are equal.
>This shows the equality is impossible. QED.
Yep.
Nick Hounsome
It is not a question of compilers.
If the platform does not have 64 bit operations the compiler for it will not
have 64 bit types even if it supports long long. (ie long long will be less
than 64 bits).
If it does have 64 bit operations then the type will almost certainly be
long.
I would only expect long long to differ from long if the machine has either:
1. support for 32, 64 and 128 bit
2. A 'natural' int size of 16 + support for 32 and 64 bit
I don't know of any common processor that fits either of these
descriptions - in the first case long would be enough for you anyway and I
doubt that the second ever existed.
In summary: the question is:
Does anyone know of any platform where long < 64 bits and long long >= 64
bits?
John Carson
news:vT5fc.124$og6...@news-binary.blueyonder.co.uk
> It is not a question of compilers.
Actually, it is since compilers can extend (or restrict) what is available
on a given system.
> If the platform does not have 64 bit operations the compiler for it
> will not have 64 bit types even if it supports long long. (ie long
> long will be less than 64 bits).
> If it does have 64 bit operations then the type will almost certainly
> be long.
> I would only expect long long to differ from long if the machine has
> either:
> 1. support for 32, 64 and 128 bit
> 2. A 'natural' int size of 16 + support for 32 and 64 bit
> I don't know of any common processor that fits either of these
> descriptions - in the first case long would be enough for you anyway
> and I doubt that the second ever existed.
>
> In summary: the question is:
> Does anyone know of any platform where long < 64 bits and long long
> >= 64 bits?
On VC++ for standard Intel Pentium (or 486) processors running Windows, long
is 32 bits and long long is 64 bits.
Nils Petter Vaskinn
> I am more interested in practical portability than in ISO standards.
> Also it seems to be irrelevant whether the 64-bit type is long or long long.
>
> Which C++ compilers do and which do not have 64-bit integer types? And
> do they have something like stdint.h?
Something like this may work if you really want it portable:
#if <some magic to detect 64bit long>
typedef long my64bit_t;
#elif <some magic to detect 64 bit long long>
typedef long long my64bit_t;
#elif <some magic to detect 64 bit int>
typedef int my64bit_t;
#else
class my64bit_t {
public:
my64bit_t();
my64bit_t(long x);
my64bit_t(unsigned char* bytes);
...
my64bit_t operator +(my64bit_t a, my64bit_t b);
...
my64bit_t operator << (my64bit_t a, int n);
...
private:
unsigned char data[8]; /* assuming 8 bit bytes */
};
/* or perhaps just #include <bigintlibrary.h> and then a single
typedef */
#endif
--
NPV
"the large print giveth, and the small print taketh away"
Tom Waits - Step right up
Peter van Merkerk
The Borland and Microsoft C++ compilers have the __int64 type and if I
remember correctly GCC has the long long type.
--
Peter van Merkerk
peter.van.merkerk(at)dse.nl
Matt
A person is lucky when he has a real expert to help him ask the right
question.
Ioannis Vranos
>
> In summary: the question is:
> Does anyone know of any platform where long < 64 bits and long long >= 64
> bits?
GCC.
Nick Hounsome
"Ioannis Vranos" <i...@guesswh.at.emails.ru> wrote in message
news:c5jm0f$b8f$1...@ulysses.noc.ntua.gr...
> "Nick Hounsome" <nh...@blueyonder.co.uk> wrote in message
> news:vT5fc.124$og6...@news-binary.blueyonder.co.uk...
> >
> > In summary: the question is:
> > Does anyone know of any platform where long < 64 bits and long long >=
64
> > bits?
>
> GCC.
gcc isn't a platform - it's just a compiler.
The size of long and long long varies with the target processor.
Bill Seurer
> "Nick Hounsome" <nh...@blueyonder.co.uk> wrote in message
> news:vT5fc.124$og6...@news-binary.blueyonder.co.uk...
>
>>In summary: the question is:
>>Does anyone know of any platform where long < 64 bits and long long >= 64
>>bits?
>
> GCC.
The native compilers on AIX and iSeries.
Matt
> gcc isn't a platform - it's just a compiler.
> The size of long and long long varies with the target processor.
Define 'platform'.
Ioannis Vranos
news:c5k1va$vra$1...@news.rchland.ibm.com...
And... ?
Ioannis Vranos
PlasmaDragon
> > Which C++ compilers do and which do not have 64-bit integer types?
>
> The Borland and Microsoft C++ compilers have the __int64 type and if I
> remember correctly GCC has the long long type.
GCC also supports __int64. I think MSVC++ may support long long int,
and, if I am not hallucinating, something called "hyper int", which is
also 64 bits long.
David Harmon
<ma...@themattfella.zzzz.com> wrote,
Development platform: a horizontal surface suitable for supporting a
heavy binder full of program listings.
See _The Zen of Programming_ by Geoffrey James
http://www.amazon.com/exec/obidos/tg/detail/-/0931137098/
Bill Seurer
And what? I was answering the question "Does anyone know of any
platform where long < 64 bits and long long >= 64 bits".
Bill Seurer
> gcc isn't a platform - it's just a compiler.
> The size of long and long long varies with the target processor.
The compiler determines the size of long and long long, not the target
processor. The target processor might limit the choices of what sizes
long and long long could be, though.
Nick Hounsome
A compiler, libraries AND processor
Nick Hounsome
"PlasmaDragon" <Plasma...@lycos.co.uk> wrote in message
news:15f1ff99.0404...@posting.google.com...
GCC does NOT support __int64 on processors that don't support 64 bit ints.
Nick Hounsome
No - the compiler is configured for the processor.
If the processor does not support 64 bit then the compiler will not normally
invent code to emulate it.
Thus if you port gcc to a processor without 64 support __int64 will not
work.
True it may well allow you to use long long but this will not be 64 bits and
will almost certainly be the
same size as long so there is no point in using it.
As a general principle it is rarely correct to just use the biggest int
available in your code and hope that
it has enough bits.
Ioannis Vranos
>
> No - the compiler is configured for the processor.
> If the processor does not support 64 bit then the compiler will not
normally
> invent code to emulate it.
> Thus if you port gcc to a processor without 64 support __int64 will not
> work.
> True it may well allow you to use long long but this will not be 64 bits
and
> will almost certainly be the
> same size as long so there is no point in using it.
> As a general principle it is rarely correct to just use the biggest int
> available in your code and hope that
> it has enough bits.
Then how .NET (and i assume Win32) has an __int64 type and compilers like
the VC++ one support it? And it *is* (behaves) as an 64 bit int.
Ioannis Vranos
Rob Williscroft
comp.lang.c++:
> "Nick Hounsome" <nh...@blueyonder.co.uk> wrote in message
> news:odLfc.17847$Z07....@news-binary.blueyonder.co.uk...
>>
>> No - the compiler is configured for the processor.
>> If the processor does not support 64 bit then the compiler will not
>> normally invent code to emulate it.
>> Thus if you port gcc to a processor without 64 support __int64 will
>> not work. True it may well allow you to use long long but this will
>> not be 64 bits and will almost certainly be thesame size as long
>> so there is no point in using it. As a general principle it is
>> rarely correct to just use the biggest intavailable in your code
>> and hope that it has enough bits.
But isn't long long the C type required to be at least 64 bits. i.e.
a long long type less than 64 bits isn't supporting any standard
and is simply useles.
>
> Then how .NET (and i assume Win32) has an __int64 type and compilers
> like the VC++ one support it? And it *is* (behaves) as an 64 bit int.
>
The same way 16 bit DOS/windows compilers (pre 386/32 bit) supported
32 bit long, by emulating it with 2 * 32 bit values.
BTW I've come across 1 compiler (I think a borland variant) that
had a __in64 type that would indeed hold 64 bit values, but I
had real problems with using them like an int (+-/*% etc).
Matt
Apparently the P4 and the AMD Athlon XPs "support 64 bit ints",
Jerry Coffin
[ ... ]
> GCC does NOT support __int64 on processors that don't support 64 bit ints.
I'm not at all convinced that _any_ version of gcc supports __int64.
Most recent versions of gcc support long long, and it works nicely on
32-bit processors, with the compiler generating sequences of 32-bit
instructions to carry out 64-bit operations.
AFAIK, __int64 is mostly a Microsoft thing, and it's supported
primarily on 32-bit processors as well. In fact, I'm not aware of
their compiler generating 64-bit instructions for __int64 operations,
even on processors such as AMD's that support them (though I'd expect
to see it in some future version of the processor). At one time, when
they produced a processor for the Alpha, that used 64-bit instructions
for __int64, but that's been gone for quite some time.
Later,
Jerry.
--
The universe is a figment of its own imagination.
David Harmon
<nh...@blueyonder.co.uk> wrote,
You just made that up.
And of the three, it is the compiler that determines the sizes of the
integral types that it provides to you.
David Harmon
<nh...@blueyonder.co.uk> wrote,
>No - the compiler is configured for the processor.
>If the processor does not support 64 bit then the compiler will not normally
>invent code to emulate it.
>Thus if you port gcc to a processor without 64 support __int64 will not
>work.
However, when Walter Bright writes Digital Mars C++
(http://www.digitalmars.com) for a processor with no 64bit
registers and no 64 bit arithmetic, __int64 does work and is 64 bits.
Any compiler that uses less than 64 bits for __int64 is just broken.
Ioannis Vranos
"Jerry Coffin" <jco...@taeus.com> wrote in message
news:b2e4b04.04041...@posting.google.com...
DJGPP which is a GCC port for Windows, supports long long as an 64-bit type.
#include <stdio.h>
#include <limits.h>
int main()
{
printf("LLONG_MAX: %lld\nLONG_MAX: %ld\n", LLONG_MAX, LONG_MAX);
}
C:\c>gcc -std=c99 -pedantic-errors temp.c -o temp.exe
C:\c>temp
LLONG_MAX: 9223372036854775807
LONG_MAX: 2147483647
C:\c>
Ioannis Vranos
Asfand Yar Qazi
>>>>> Does anyone know of any platform where long < 64 bits and long long >=
>>
>>
>> 64
>>
>>>>> bits?
>>>>
>>>>
>>>> GCC.
>>>
>>>
>>> The native compilers on AIX and iSeries.
>>
>>
>> And... ?
>
>
> And what? I was answering the question "Does anyone know of any
> platform where long < 64 bits and long long >= 64 bits".
I believe that x86-32 gcc has long of 32-bits (32 < 64) and long long
64-bits (64 >= 64).
red floyd
Since __int64 is not part of the standard, a compiler is free to use whatever
the hell it wants for that.
Matt
I thank you and comp.lang.c++ thanks you.
Jack Walker
Well .NET is a virtual processor system like the JVM so every type it
supports is emulated in software.
Jack Walker
>
>
>
>
>
> Ioannis Vranos
Jack Walker
> On Tue, 13 Apr 2004 21:19:04 +0000, Matt wrote:
>
> > I am more interested in practical portability than in ISO standards.
> > Also it seems to be irrelevant whether the 64-bit type is long or long long.
> >
> > Which C++ compilers do and which do not have 64-bit integer types? And
> > do they have something like stdint.h?
>
>
> #if <some magic to detect 64bit long>
> typedef long my64bit_t;
> #elif <some magic to detect 64 bit long long>
> typedef long long my64bit_t;
> #elif <some magic to detect 64 bit int>
> typedef int my64bit_t;
> #else
> class my64bit_t {
> public:
> my64bit_t();
> my64bit_t(long x);
> my64bit_t(unsigned char* bytes);
> ...
>
> my64bit_t operator +(my64bit_t a, my64bit_t b);
>
> ...
> my64bit_t operator << (my64bit_t a, int n);
> ...
> private:
> unsigned char data[8]; /* assuming 8 bit bytes */
> };
>
> /* or perhaps just #include <bigintlibrary.h> and then a single
> typedef */
> #endif
Here is a possible challange: Write a template meta program to define
the afforementioned type.
Jack Walker
Ioannis Vranos
news:b4220662.04042...@posting.google.com...
>
> > Then how .NET (and i assume Win32) has an __int64 type and compilers
like
> > the VC++ one support it? And it *is* (behaves) as an 64 bit int.
> >
>
> Well .NET is a virtual processor system like the JVM so every type it
> supports is emulated in software.
But .NET is not yet an 64-bit virtual machine.
DJGPP also provides 64 bit integer type, as also MINGW (both GCC ports).
#include <iostream>
#include <limits>
// Not ISO C++98 code
int main()
{
using namespace std;
cout<<numeric_limits<long long>::max()<<endl;
cout<<numeric_limits<long>::max()<<endl;
}
C:\c>gpp temp.cpp -o temp
C:\c>temp
9223372036854775807
2147483647
C:\c>\mingw\bin\g++ temp.cpp -o temp
C:\c>temp
9223372036854775807
2147483647
And of course GCC for 32-bit GNU/Linux does the same.
Ioannis Vranos