unsigned int support

[faz]

Dear all,

May i know the data type which can support FFFF FFFF FFFF
FFFF(18,446,744,073,709,551,615).I have declared a variable using
unsigned integer type which is supporting upto FFFF
FFFF(4,294,967,295).pls suggest me..

Thanks in advance,
faz

 

[Jim Langston]

Dear all,

May i know the data type which can support FFFF FFFF FFFF
FFFF(18,446,744,073,709,551,615).I have declared a variable using
unsigned integer type which is supporting upto FFFF
FFFF(4,294,967,295).pls suggest me..

You need a 64 bit int. You need a 64 bit compiler. Check your compiler
documentation if you have a 64 bit compiler. It may be long int, or long
long int or something.

 

[Ian Collins]

You need a 64 bit int. You need a 64 bit compiler. Check your compiler
documentation if you have a 64 bit compiler. It may be long int, or long
long int or something.

Or rather the OP needs (unsigned) long long, which often does not
require a 64 bit compiler (whatever that might be).

 

[Neelesh Bodas]

Dear all,

May i know the data type which can support FFFF FFFF FFFF
FFFF(18,446,744,073,709,551,615).I have declared a variable using
unsigned integer type which is supporting upto FFFF
FFFF(4,294,967,295).pls suggest me..

Thanks in advance,
faz

Sizes of datatypes and also the range of the values that they can
represent are implementation defined. The macros INT_MAX and UINT_MAX
defined in <climits> will let you know the maximum value an integral
type defined by your compiler.


-N

 

[Jim Langston]

Or rather the OP needs (unsigned) long long, which often does not
require a 64 bit compiler (whatever that might be).

I don't think that unsigned long long is guaranteed to be 64 bit in all
implentations, is it? As I understood it the only requirements was
something along the lines of:

char >= short >= int etc...

 

[Jim Langston]

I don't think that unsigned long long is guaranteed to be 64 bit in all
implentations, is it? As I understood it the only requirements was
something along the lines of:

char >= short >= int etc...

Ack, of course I meant
char <= short <= int etc...

 

[Neelesh Bodas]

Or rather the OP needs (unsigned) long long, which often does not
require a 64 bit compiler (whatever that might be).

long long int has not yet made into the standard.
[such a datatype might however be available on OP's compiler]

 

[Neelesh Bodas]

long long int has not yet made into the standard.

Or has it? I just noted that I have older copy of the standard [98]

 

[Ian Collins]

I don't think that unsigned long long is guaranteed to be 64 bit in all
implentations, is it? As I understood it the only requirements was
something along the lines of:

long long isn't part of the C++ standard (yet), but C99 defines the
minimum value for ULLONG_MAX as 2^64-1.

 

[Alf P. Steinbach]

* Neelesh Bodas:

long long int has not yet made into the standard.

Or has it? I just noted that I have older copy of the standard [98]

No, "long long" i's not yet part of the standard, although "long double" is.

However, if all the OP needs is the ability to hold 64 bits, and perhaps
do some bit-juggling, then that's trivial:

typedef std::bitset<64> Bits64;

Or, for doing arithmetic a good start is

namespace yumyum
{
typedef SOME_INTRINSIC_UINT_TYPE CppUInt32;

struct UInt64
{
private:
CppUint32 myLow;
CppUint32 myHigh;
public:
...
};
}

And it may happen that the OS supports such a type directly at the API
level, so that all that's required for usability is a C++ wrapper (e.g.,
Windows does support this). Or for efficiency one might consider some
inline assembler in the implementation. Although I wouldn't do that
until efficiency became a concern, if ever.

Hth.,

- Alf

 

[James Kanze]

You need a 64 bit int. You need a 64 bit compiler. Check
your compiler documentation if you have a 64 bit compiler. It
may be long int, or long long int or something.

C99 requires long long, and requires it to be at least 64 bits.
It will be required in the next version of the C++ standard, and
it's hard to imagine a modern C++ compiler which doesn't support
it. (All of the Unix compilers I know of do, as does VC++.)

If you have to deal with an older compiler, particularly on a
non-Unix platform, you may have problems with it, but otherwise
no. (Earlier versions of VC++ had _int64, I believe.)

 

[James Kanze]

No, "long long" i's not yet part of the standard,

That depends which standard: it's in C99, in the current draft
C++ standard, and in every current C++ compiler I know of.
Unless you explicitly have to deal with older compilers (e.g.
VC++ 6.0), you can pretty much count on it.

 

[Alf P. Steinbach]

* James Kanze:

That depends which standard: it's in C99, in the current draft
C++ standard, and in every current C++ compiler I know of.
Unless you explicitly have to deal with older compilers (e.g.
VC++ 6.0), you can pretty much count on it.

The standard for this group is the current C++ standard.

There's no "long long" in the standard.

Cheers,

- Alf

 

[Ian Collins]

* James Kanze:

The standard for this group is the current C++ standard.

There's no "long long" in the standard.

But it has become ubiquitous and it is easy to test for.

 

[Alf P. Steinbach]

* Ian Collins:

But it has become ubiquitous and it is easy to test for.

T:\> cat <bah.cpp
int main() { long long bah; }

T:\> gnuc --version
g++ (GCC) 3.4.4 (mingw special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.


T:\> gnuc bah.cpp
bah.cpp: In function `int main()':
bah.cpp:1: error: ISO C++ does not support `long long'
bah.cpp:1: warning: unused variable 'bah'

T:\> _

 

[Ian Collins]

* Ian Collins:

T:\> cat <bah.cpp
int main() { long long bah; }

T:\> gnuc --version
g++ (GCC) 3.4.4 (mingw special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.


T:\> gnuc bah.cpp
bah.cpp: In function `int main()':
bah.cpp:1: error: ISO C++ does not support `long long'
bah.cpp:1: warning: unused variable 'bah'

So what ever "gnuc" is, it is invoking g++ in pedantic mode. You have
the choice of being pedantic, or pragmatic. If you had to do 64 bit
math, which would you prefer?

By easy to test for, I was thinking of something along the lines of

#include <limits.h>

int main() {
#if !defined ULLONG_MAX
# SomeBigIntClass bah;
#else
long long bah;
#endif
}

 

[faz]

I have tried this using VC++ 1998(older version)

int main()
{
long long bas;
return 0;

}


D:\Program Files\Microsoft Visual Studio\my projects\link list
\long.cpp(4) : error C2632: 'long' followed by 'long' is illegal
Error executing cl.exe.

long.obj - 1 error(s), 0 warning(s)

Not supported...I guess my compiler is 32-bit....Which compiler
support this??

regards,
faz

 

[Michael DOUBEZ]

faz a écrit :

I have tried this using VC++ 1998(older version)

int main()
{
long long bas;
return 0;

}


D:\Program Files\Microsoft Visual Studio\my projects\link list
\long.cpp(4) : error C2632: 'long' followed by 'long' is illegal
Error executing cl.exe.

long.obj - 1 error(s), 0 warning(s)

Not supported...I guess my compiler is 32-bit....Which compiler
support this??

long long was introduced in C99. It is not really a surprise a compiler
didn't know about it in 98.

Michael

 

[Pete Becker]

long long int has not yet made into the standard.

Or has it? I just noted that I have older copy of the standard [98]

long long and unsigned long long are in the Working Draft for C++0x.

 

[Pete Becker]

Sizes of datatypes and also the range of the values that they can
represent are implementation defined. The macros INT_MAX and UINT_MAX
defined in <climits> will let you know the maximum value an integral
type defined by your compiler.

Those macros give you the maximum values for int and unsigned int.