C and only C language has a standard 64 bit integer type ?

T

Timothy Madden

Hello

I've read here that only C language has a standard 64bit integer.
Can you please tell me what are the reasons for this ? What is special about
C language ?

Can you please show me some references to this integer type ? When was it
introduced ?

Thank you
Timothy Madden
Romania
 
R

Rob Williscroft

Timothy Madden wrote in in
comp.lang.c++:
Hello

I've read here that only C language has a standard 64bit integer.
Can you please tell me what are the reasons for this ? What is special
about C language ?

Can you please show me some references to this integer type ? When was
it introduced ?


On this page:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/

you will find a reference to:

N1565 04-0005 Adding the long long type to C++ J. Stephen Adamczyk
2004-01-22 04-02 Evolution

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1565.pdf


Note, bookmark:

http://www.open-std.org/jtc1/sc22/wg21/

If you're intrested in the future direction of the standard.

HTH.

Rob.
 
R

Rolf Magnus

Timothy said:
Hello

I've read here that only C language has a standard 64bit integer.

That's not quite it. The integer types don't have fixed sizes, they only
have minimum sizes. And it happens that C has the type "long long", which
is required to be at least 64bit, and C++ doesn't.
Can you please tell me what are the reasons for this ?

The C++ language standard is based on the C89 standard, which doesn't have
"long long" either. The new version of the C standard that contains the new
type was finished one year after the C++ standard.
What is special about C language ?

Can you please show me some references to this integer type ? When was it
introduced ?

In the C99 standard.
 
G

Greg Comeau

I've read here that only C language has a standard 64bit integer.
Can you please tell me what are the reasons for this ? What is special about
C language ?

Other language have 64 bits types I'm sure.
C added it for the same reason as some of the others,
machines were coming along which supported it and it was time.
Can you please show me some references to this integer type ?

The intent of 'long long' is to provide 64 bit support,
as a minimum (so for instance, it may support 128 bits too).
When was it introduced ?

Formally with C99. Informally for a real long time.
For instance, most C++ compilers also support it as an extension
even though Standard C++ does not discuss its support for it.
 
J

Jack Klein

Hello

I've read here that only C language has a standard 64bit integer.

No, C has defined the signed and unsigned 'long long' integer types
that must contain at least 64 bits, but could have more.

But it is not "only C", just merely not C++. Java, for example, has
exact-width 64-bit integer types, as do some other languages.
Can you please tell me what are the reasons for this ? What is special about
C language ?

Most of the things that are special about C have nothing at all to do
with this.

As for the reasons, disk drives today cost less than $1.00USD per
gigabyte of storage. It is not even uncommon in some types of
applications to have files containing more than 32 bits worth of
octets.

On a busy trading day, the NASDAQ stock exchange can trade more shares
than can be counted in a signed 32-bit integer type, and the NASDAQ
and AMEX together more than can be counted in an unsigned 32-bit
integer.

Computers today, even 32-bit ones not to mention 64-bit ones, can
easily have enough memory that they can have arrays larger than 2^32
bytes in size, so there must be signed and unsigned integer types
large enough to be size_t and ptrdiff_t for these to work.

Just to name a few situations where an integer type with a width
greater than 32 bits is needed.

The real question is why the C++ standard, being finalized not too
much before the 1999 major update to the C standard, did not include
the 'long long' type or indeed all of the expansions to the integer
types that C added in 1999.
 
G

Greg Comeau

The real question is why the C++ standard, being finalized not too
much before the 1999 major update to the C standard, did not include
the 'long long' type or indeed all of the expansions to the integer
types that C added in 1999.

It seems to me (I don't have the spec in front of me) three overall
issues were/are at hand: is "long long" the best "spelling"/form
for C++, are all the "new" C99 long long related issues acceptable,
is there other alternatives especially in consideration of future
direction. I'm not saying those things could not have been
duked out, just that as often is the case, there is not a
straighforward answer. For instance, I suppose if we wanted to,
we could say this was a real question for C90, or for some C before
C99 too, and the reasons it was not added previously to C
are probably as varied as they are for C++.
 
T

Timothy Madden

Jack Klein said:
No, C has defined the signed and unsigned 'long long' integer types
that must contain at least 64 bits, but could have more.

But it is not "only C", just merely not C++. Java, for example, has
exact-width 64-bit integer types, as do some other languages.


Most of the things that are special about C have nothing at all to do
with this.

As for the reasons, disk drives today cost less than $1.00USD per
gigabyte of storage. It is not even uncommon in some types of
applications to have files containing more than 32 bits worth of
octets.

On a busy trading day, the NASDAQ stock exchange can trade more shares
than can be counted in a signed 32-bit integer type, and the NASDAQ
and AMEX together more than can be counted in an unsigned 32-bit
integer.

Computers today, even 32-bit ones not to mention 64-bit ones, can
easily have enough memory that they can have arrays larger than 2^32
bytes in size, so there must be signed and unsigned integer types
large enough to be size_t and ptrdiff_t for these to work.

Just to name a few situations where an integer type with a width
greater than 32 bits is needed.

The real question is why the C++ standard, being finalized not too
much before the 1999 major update to the C standard, did not include
the 'long long' type or indeed all of the expansions to the integer
types that C added in 1999.

I understand now
It's because the new type is named 'long long'.
It is really ugly for a standard type.
They could have just said number, integer, real, numeric, natural or
something ...
Pascal has a special large numeric type named 'comp' for example
(implemented with floats)
Language designers had more imagination it it's case, and nobody asked why
the type is named 'comp'

Timothy Madden
Romania
 
I

Ioannis Vranos

Timothy said:
I understand now
It's because the new type is named 'long long'.
It is really ugly for a standard type.
They could have just said number, integer, real, numeric, natural or
something ...
Pascal has a special large numeric type named 'comp' for example
(implemented with floats)
Language designers had more imagination it it's case, and nobody asked why



Or something like int64, etc.

That said, nothing restricts an implementation to provide a long of 64
bits, since long is at least 32 bits. And personally I do not favour the
addition of a new type, since long can do the job.
 
D

Default User

Rolf said:
That's not quite it. The integer types don't have fixed sizes, they
only have minimum sizes. And it happens that C has the type "long
long", which is required to be at least 64bit, and C++ doesn't.


It should be noted that the new C standard also mentions exact-width
types, although these are optional. Most C99 compilers will likely
provide them.




Brian Rodenborn
 
V

Victor Bazarov

Ioannis said:
Or something like int64, etc.

That said, nothing restricts an implementation to provide a long of 64
bits, since long is at least 32 bits. And personally I do not favour the
addition of a new type, since long can do the job.

You're missing the point, probably. Yes, on some platforms 'long int' can
do the job, but adding a new type to the language would ensure that on
_all_ platforms there is something that is at least 64 bits. 'long int'
is only guaranteed to be 32 bits, so we are still facing with some kind of
compatibility problem when porting 64-bit-enabled code from one platform
to another.

Victor
 
I

Ioannis Vranos

Victor said:
You're missing the point, probably. Yes, on some platforms 'long int' can
do the job, but adding a new type to the language would ensure that on
_all_ platforms there is something that is at least 64 bits. 'long int'
is only guaranteed to be 32 bits, so we are still facing with some kind of
compatibility problem when porting 64-bit-enabled code from one platform
to another.


What about a new guarantee that long is at least 64-bit? It is a
"superset" of the guarantee that it is at least 32-bit.
 
V

Victor Bazarov

Ioannis said:
What about a new guarantee that long is at least 64-bit? It is a
"superset" of the guarantee that it is at least 32-bit.

Such requirement would probably make many programs running today utterly
inefficient on the multitude of 16-bit platforms. Imagine that all 32-bit
calculations would have to be replaced with 64-bit ones.

V
 
G

Greg Comeau

You're missing the point, probably. Yes, on some platforms 'long int' can
do the job, but adding a new type to the language would ensure that on
_all_ platforms there is something that is at least 64 bits. 'long int'
is only guaranteed to be 32 bits, so we are still facing with some kind of
compatibility problem when porting 64-bit-enabled code from one platform
to another.

I agree there is minimum requirements, but in the end you don't
escape the compatibility for all possibilities, you just change the
landscape. I'm not saying that's inherently bad, but adding
a new type whether 64 bits or min 64 bits is of course not the
only way to ensure you have get 64 bits. Of course, all the
alternatives change the landscape. But we have to agree other
language such as FORTRAN have had syntax like type*N for a long time
and it's a matter of a number of things. I can't imagine that
in the next twenty years we'll have 'long long long' and worse,
not to mention all the extended interger type stuff, conversion
rules, etc. (I know you're not saying any of this, I'm just
speaking out loud a bit.)
 
I

Ioannis Vranos

Victor said:
Such requirement would probably make many programs running today utterly
inefficient on the multitude of 16-bit platforms. Imagine that all 32-bit
calculations would have to be replaced with 64-bit ones.


long long will not be inefficient in those systems? If you have such
portability-to-16 bits concerns, you should use int in the first place.
 
V

Victor Bazarov

Ioannis said:
long long will not be inefficient in those systems?

Most likely it won't.
If you have such
portability-to-16 bits concerns, you should use int in the first place.

Why? What if 'int' doesn't cut it? What if I need 28 bits? I shouldn't
have to waste time and memory dealing with 64 bit types if it can all be
handled by 32 bits.
 
I

Ioannis Vranos

Victor said:
Why? What if 'int' doesn't cut it? What if I need 28 bits? I shouldn't
have to waste time and memory dealing with 64 bit types if it can all be
handled by 32 bits.


OK I can understand such a need.In the case of extensions in the type
system, the approach taken should be extensible.

Leaving C aside since it is a different language, what about introducing
int64 being exactly 64 bit, int32 being exactly 32 bits and int16 being
exactly 16 bits, and making int equivalent to int16, and long being
equivalent to int32?
 
V

Victor Bazarov

Ioannis said:
OK I can understand such a need.In the case of extensions in the type
system, the approach taken should be extensible.

Leaving C aside since it is a different language, what about introducing
int64 being exactly 64 bit, int32 being exactly 32 bits and int16 being
exactly 16 bits, and making int equivalent to int16, and long being
equivalent to int32?

What about them? I am fairly certain the work either has been started on
those and a proposal is already there waiting for the next major Standard
release, or work is being performed on a proposal. Ask in comp.std.c++
if you are interested.

V
 
I

Ioannis Vranos

Victor said:
What about them? I am fairly certain the work either has been started on
those and a proposal is already there waiting for the next major Standard
release, or work is being performed on a proposal. Ask in comp.std.c++
if you are interested.


I am not talking about long long, int64_t etc crap but for built in types.
 
V

Victor Bazarov

Ioannis said:
I am not talking about long long, int64_t etc crap but for built in types.

If there were no need for built-in types of specific sizes before, I do
not think there is a need for them now. But that's just my opinion. If
yours is different, state it and give some background. Why do you think
they should be built-in instead of, say, typedef'ed? What's the advantage
of having N new keywords instead of N new types in the 'std' namespace?
And if you think you have enough for a convincing argument, why don't you
go to comp.std.c++ and post a proposal?

V
 
I

Ioannis Vranos

Victor said:
If there were no need for built-in types of specific sizes before, I do
not think there is a need for them now. But that's just my opinion. If
yours is different, state it and give some background. Why do you think
they should be built-in instead of, say, typedef'ed? What's the advantage
of having N new keywords instead of N new types in the 'std' namespace?
And if you think you have enough for a convincing argument, why don't you
go to comp.std.c++ and post a proposal?


I have already posted a proposal in both c.l.c++.m. and c.std.c++.

About the typedefs, why would "exotic" (not corresponding to built in
types) integral typedefs be better than built in integer types?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top