64 bit ints?

64 bit signed integer:
with GCC: signed long long int
in Windows: signed __int64

You don't need any header in GCC. It's a normal type like an int or a char. For 64 bit floating point you can use 'double' both in windows and with GCC.

[edited by - Rule on December 28, 2003 5:06:05 PM]

your supposed to use
hyper
uhyper
now-a-days


it just maps it across to __int64 on windows platforms, to the long long in from unix/solaris, and to the normal 64bit integers on 64bit machines.

Even when your platform doesn''t support __int64, hyper will force it to use a software version.


That''s why they made hyper and uhyper in the first place.

I''m NOT sure if its C++ only (as in non C).

quote:

---

Original post by Dredge-Master
your supposed to use
hyper
uhyper
now-a-days

---

Have they put that in either C99 or ANSI/ISO? Or just the latest new thing?

Usually you use long long on GCC and __int64 on Visual Studio.

Are operations on 64 bit integers as fast as on their 32bit counterparts?

long long is defined in both GCC and VS.NET.

quote:

---

Original post by fallenang3l
Are operations on 64 bit integers as fast as on their 32bit counterparts?

---

If you had a 64 bit cpu.

[edited by - smart_idiot on December 28, 2003 12:47:54 AM]

smart_idiot isn''t neccessarily right.

On 32-bit machines the 64-bit operations need to be broken down (by the compiler, usually) into collections of 32-bit instructions. This means 64-bit instructions can take between 2 and 32 times as long (add takes ~4x, divide I think is ~16x). Of course, that depends on the architecture.

On native 64-bit machines a 64-bit operation is still likely to take slightly longer than a 32-bit operation (provided the 64-bit machine has 32-bit instructions (most do, x86 has 16 bit instructions)). But probably only in the order of 20-50% longer unless it''s a complex operation like divide.

If the 64-bit machine doesn''t have 32-bit instructions, 32 bit might even be slower, but this is probably a rare case.

I may have some of the facts wrong, but in general I think they are correct.

quote:

---

Original post by Promit

quote:

---

Original post by Dredge-Master
your supposed to use
hyper
uhyper
now-a-days

---

Have they put that in either C99 or ANSI/ISO? Or just the latest new thing?

Usually you use long long on GCC and __int64 on Visual Studio.

---

It''s supposed to be. It''s part of the standard libraries. ALOT of compilers don''t have it in there (still using the old ones).

For compilers that completely comply to the standards, they will have hyper and uhyper in there.

nb: MSVC isn''t an ANSI complient compiler. It does have hyper in it, but it has really bad compliance when defining variables in loops etc. It''s faster though, but it ins''t complient.

anyway, hyper should be there.

nb: on win32 systems, it is the same as signed __int64 and unsigned __int64. unix and macs use the signed long long int and unsigned long long int. 64 bit systems are normal ints. The whole point of it was to give it a cross platform typedef.

quote:

---

Original post by Krylloan
smart_idiot isn''t neccessarily right.

---

Classic quote in itself.

Now that we''re stepping into the 64 bit era, is there something we can use for 128 bit integers?

quote:

---

Original post by Dredge-Master
your supposed to use
hyper
uhyper
now-a-days

---

I think you''re confused. hyper and unsigned hyper are XDR names for 64 bit integers, and even in XDR uhyper is not a standard abbreviation for unsigned hyper. The word "hyper" never shows up in IEC 14882:1998 nor in IEC 14882:2003, the C++ standards.