unsigned int support

[Alf P. Steinbach]

* Ian Collins:

So what ever "gnuc" is, it is invoking g++ in pedantic mode. You have
the choice of being pedantic, or pragmatic.

Using pedantic mode /is/ the pragmatic choice.

Not using pedantic mode isn't pragmatic.

It's just ostrich policy: hide yer head in the sand and assume that
since one doesn't see the enemy (non-portable and dubious code
constructs), the enemy isn't there, or at least, doesn't attack you.

If you had to do 64 bit math, which would you prefer?

Weight the need for 64-bit integer math against the need for using
compilers that doesn't yet support it, or alternatively the cost of
implementing it. On the surface it's not so much an engineering
decision as a management decision, a cost/benefit decision. However,
most compilers, even pedantic mode Ming g++ 3.4.4, support 64-bit
integers, just not non-standard "long long", so implementing it seems to
be very trivial (weasel-words "seems to be": this is just off-the-cuff):

T:\> cat <bah.cpp
#include <iostream>
#include <ostream>

#ifdef __GNUC__
# define EXTENSION __extension__
#else
# define EXTENSION
#endif

EXTENSION typedef unsigned long long ULongLong;

int main()
{
using namespace std;
cout << hex << ULongLong(-1) << endl;
}

T:\> gnuc bah.cpp & a
ffffffffffffffff

T:\> _

I think this is the proper, pragmatic, pedantic way... ;-)

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
}

Uhm, I think you're right that it's easy to test for, using some
implementation of the C header that provides fixed size ints (whatever
it was called, I think it's part of C++ TR1), but the above fails:

T:\> cat <bah.cpp
#include <iostream>
#include <ostream>
#include <climits>

#define STRINGVALX(tok) #tok
#define STRINGVAL(tok) STRINGVALX( tok )

int main()
{
using namespace std;
cout << STRINGVAL(ULLONG_MAX) << endl;
}

T:\> gnuc bah.cpp & a
(2ULL * 9223372036854775807LL + 1)

T:\> _

Reason for test failure that <climits> provides C99 macros...

But see also middle of this posting.

 

[joe]

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

As was briefly mentioned earlier, for earlier versions of VC, you want
the __int64 or unsigned __int64 type rather than long long. The more
recent versions of VC have added the long long type in anticipation of
the draft C++ standard.

joe

 

[James Kanze]

faz a écrit :

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

Actually, it was introduced in one of the Unix standards long
before that. From what I understand, the ISO C committee didn't
particularly like it; what do you write in ten years time, for
128 bit ints: long long long? But even at the time the 1999
standard was being finalized (1997 or before), it was too
ubiquious to be ignored.

In the case of Visual Studios, of course, the Unix standards
aren't applicable, and VC++ actually did something more
intelligent, defining a type _int64 (which extends in a rather
obvious fashion, *and* is sort of in the implementation
namespace, although as a keyword, it really needs two
underscores). Also, compilers have a certain lead time as well,
and it wasn't at all clear that those opposing long long in C99
wouldn't have their way until fairly late in the standardization
process, so all Microsoft can be accused of here is not
respecting the Unix standards.

Once C formally adopted it, of course, it was fairly obvious
that C++ would follow suite (as it has). I think it safe to say
that any C++ compiler less than three or four years old should
support it. (I still use GB_longlong and GB_ulonglong, though.
Types defined in a system dependant header. Just in case I run
into an older compiler.)

 

[James Kanze]

* James Kanze:

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

The standard for this group is "portable C++", whatever that
means. Depending on your exact portability requirements, it
would be stupid not to use it. Or to use it, depending, as I
said, on your portability requirements.

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

Depends on which standard.

 

[James Kanze]

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

It might also be worth pointing out that you can easily test for
long long by means of such macros:

#include <limits.h>
#ifdef LLONG_MAX
typedef long long MyLongLong ;
#else
???
#endif

 

[Alf P. Steinbach]

* James Kanze:

The standard for this group is "portable C++", whatever that
means.

There's no such standard. References to the standard are references to
the current C++ standard. When nothing else is explicitly indicated.

 

[BobR]

I don't think that unsigned long long is guaranteed to be 64 bit in all
implentations, is it?

Soon! GNU's had it for a while. <G>

[ GCC(MinGW)3.3.1, win98se, iP4]
// #include <limits>

std::cout <<" LL digits ="
<<(std::numeric_limits<long long>::digits)<<std::endl;
// LL digits =63

std::cout <<" ULL digits ="
<<(std::numeric_limits<unsigned long long>::digits)<<std::endl;
// ULL digits =64

std::cout<<" LD digits ="
<<(std::numeric_limits<long double>::digits)<<std::endl;
// LD digits =64