By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,969 Members | 2,250 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,969 IT Pros & Developers. It's quick & easy.

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

P: n/a
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
-------------------------------------------------
And I don't wanna miss a thing
Jul 22 '05 #1
Share this Question
Share on Google+
28 Replies


P: n/a
Timothy Madden wrote in news:2r*************@uni-berlin.de 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/wg...s/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/wg...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.
--
http://www.victim-prime.dsl.pipex.com/
Jul 22 '05 #2

P: n/a
Timothy Madden wrote:
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.
Jul 22 '05 #3

P: n/a
On Mon, 20 Sep 2004 12:10:28 +0300, "Timothy Madden"
<ba****@rmv.spam.home.ro> wrote in comp.lang.c++:
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.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Jul 22 '05 #4

P: n/a

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:t5********************************@4ax.com...
On Mon, 20 Sep 2004 12:10:28 +0300, "Timothy Madden"
<ba****@rmv.spam.home.ro> wrote in comp.lang.c++:
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.


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
----------------------------------------
And I don't wanna miss a thing
Jul 22 '05 #5

P: n/a
Timothy Madden wrote:
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


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.

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 22 '05 #6

P: n/a
Ioannis Vranos wrote:
Timothy Madden wrote:
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



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
Jul 22 '05 #7

P: n/a
Victor Bazarov wrote:
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.

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 22 '05 #8

P: n/a
Rolf Magnus wrote:
Timothy Madden wrote:
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.

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
Jul 22 '05 #9

P: n/a
Ioannis Vranos wrote:
Victor Bazarov wrote:
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.


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
Jul 22 '05 #10

P: n/a
Victor Bazarov wrote:
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.

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 22 '05 #11

P: n/a
Ioannis Vranos wrote:
Victor Bazarov wrote:
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?


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.
Jul 22 '05 #12

P: n/a
Victor Bazarov wrote:
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?

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 22 '05 #13

P: n/a
Ioannis Vranos wrote:
Victor Bazarov wrote:
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?


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
Jul 22 '05 #14

P: n/a
Victor Bazarov wrote:
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.

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 22 '05 #15

P: n/a
Ioannis Vranos wrote:
Victor Bazarov wrote:
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.


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
Jul 22 '05 #16

P: n/a
Victor Bazarov wrote:
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?

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 22 '05 #17

P: n/a
Ioannis Vranos wrote:
Victor Bazarov wrote:
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?


Because built-in types require new keywords. Adding new keywords to
an existing language is _always_ problematic. Just take C's "_Bool"
as an example of the ugliness that ensues.

V
Jul 22 '05 #18

P: n/a
Victor Bazarov wrote:
Because built-in types require new keywords. Adding new keywords to
an existing language is _always_ problematic. Just take C's "_Bool"
as an example of the ugliness that ensues.

I do not agree with Cs extension approach. bool would be sufficient and
codifies pre-existing practice.
Also many compilers already use long long. If it is accepted for C++0x,
should it be introduced as __Long long?

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 22 '05 #19

P: n/a
Ioannis Vranos wrote:
Victor Bazarov wrote:
Because built-in types require new keywords. Adding new keywords to
an existing language is _always_ problematic. Just take C's "_Bool"
as an example of the ugliness that ensues.
I do not agree with Cs extension approach. bool would be sufficient and
codifies pre-existing practice.


Well, I don't mean to be rude, but who cares that you don't agree? It
is not up for discussion, when C is concerned.
Also many compilers already use long long. If it is accepted for C++0x,
should it be introduced as __Long long?


You again are missing the point. 'long long' is not an introduction of
a new keyword, it's a correction in the grammar. However, int64 or
any other name that you can come up with for a fixed-size type would be
an introduction of a new keyword. Do you propose to have 'long char' or
'short char' to designate 32-bit or 8-bit types?

V
Jul 22 '05 #20

P: n/a
Victor Bazarov wrote:
You again are missing the point. 'long long' is not an introduction of
a new keyword, it's a correction in the grammar.

?It is a new type.

However, int64 or
any other name that you can come up with for a fixed-size type would be
an introduction of a new keyword. Do you propose to have 'long char' or
'short char' to designate 32-bit or 8-bit types?

? No. How did you reach such a conclusion. What I propose is:
int16 is introduced and is an exact 16-bit type (of course additional
padding bits are allowed). int and short become equivalent of it.

That is, signed int16, int16, signed, signed int, int, signed short,
short to be all equivalent. The same for the unsigned equivalents. That
is unsigned int16 to be the same as unsigned int and unsigned, etc.

int32 is introduced and holds exactly 32-bit values. long becomes
another name of it, as was the case with the above.

signed int32, int32, signed long, long are all the same.
int64 is introduced and holds 64-bit values. signed int64 is equivalent
and unsigned int64 is the unsigned type.
So we can say:

int64 x;

int32 *p = new int32[10];

long *pp = p;
etc.

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 22 '05 #21

P: n/a
Ioannis Vranos wrote:
Victor Bazarov wrote:
You again are missing the point. 'long long' is not an introduction of
a new keyword, it's a correction in the grammar.
?It is a new type.


So? It's not a new keyword. 'long' already exists in the language. It
is just a new use for an old keyword.
However, int64 or
any other name that you can come up with for a fixed-size type would be
an introduction of a new keyword. Do you propose to have 'long char' or
'short char' to designate 32-bit or 8-bit types?


? No. How did you reach such a conclusion. What I propose is:
int16 is introduced


Are you tired today, or perhaps have a headache? 'int16' is a new keyword.
I just told you that introduction of a new keyword is NOT likely to be
accepted.
[...]

Jul 22 '05 #22

P: n/a
Victor Bazarov wrote:
Ioannis Vranos wrote:
Victor Bazarov wrote:
Because built-in types require new keywords. Adding new keywords to
an existing language is _always_ problematic. Just take C's "_Bool"
as an example of the ugliness that ensues.


I do not agree with Cs extension approach. bool would be sufficient and
codifies pre-existing practice.


Well, I don't mean to be rude, but who cares that you don't agree? It
is not up for discussion, when C is concerned.
Also many compilers already use long long. If it is accepted for C++0x,
should it be introduced as __Long long?


You again are missing the point. 'long long' is not an introduction of
a new keyword, it's a correction in the grammar. However, int64 or
any other name that you can come up with for a fixed-size type would be
an introduction of a new keyword. Do you propose to have 'long char' or
'short char' to designate 32-bit or 8-bit types?


Perhaps

int<64> var;

Etc. No idea if that would present other problems.

Scott

Jul 22 '05 #23

P: n/a

"Timothy Madden" <ba****@rmv.spam.home.ro> wrote in message
news:2r*************@uni-berlin.de...
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 ?


Can you please tell me why is a new keyword not likely to be accepted ?
And why do people seem to want fixed-sized integer types ?
I want a new type for a 64-bit integer, but I don't want the standard to
impose this limit on
it and I definetly don't want it named int64. In a conforming implementation
short int and long int can actualy be the same. They can actualy be
implemented with chars and the implementation would still be confromant.

I think these existing loose limits on integer types are a good thing and I
don't want the
rule broken just to introduce a new integer type

Thank you
Timothy Madden
Romania
-----------------------------------------------
And I don't wanna miss a thing
Jul 22 '05 #24

P: n/a
In article <2r*************@uni-berlin.de>,
Timothy Madden <ba****@rmv.spam.home.ro> wrote:
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.
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 22 '05 #25

P: n/a
In article <t5********************************@4ax.com>,
Jack Klein <ja*******@spamcop.net> wrote:
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++.

--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 22 '05 #26

P: n/a
In article <fC****************@newsread1.dllstx09.us.to.verio .net>,
Victor Bazarov <v.********@comAcast.net> wrote:
Ioannis Vranos wrote:
Timothy Madden wrote:
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


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.


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.)
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 22 '05 #27

P: n/a
On Mon, 20 Sep 2004 19:46:08 +0300, Timothy Madden wrote:
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 ...

When you're making a standard, the most important thing is that everyone
agrees, not that it's the absolute best technical solution that "wins"
(which anyway seems rather subjective).
And standarization is also about bringing already widely used things to
a standard form. long long has been used for a long time by vendors...
Jul 22 '05 #28

P: n/a
Nils O. Selåsdal wrote:
When you're making a standard, the most important thing is that everyone
agrees, not that it's the absolute best technical solution that "wins"
(which anyway seems rather subjective).
And standarization is also about bringing already widely used things to
a standard form. long long has been used for a long time by vendors...

As also int64 in various forms. In .NET the type larger than long is
__int64.

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 22 '05 #29

This discussion thread is closed

Replies have been disabled for this discussion.