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

[Victor Bazarov]

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

 

[Ioannis Vranos]

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?

 

[Victor Bazarov]

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

 

[Ioannis Vranos]

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.

 

[Victor Bazarov]

?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.

? 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.

[...]

 

[scott urban]

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.


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

 

[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 ?

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

 

[=?iso-8859-1?q?Nils_O=2E_Sel=E5sdal?=]

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...

 

[Ioannis Vranos]

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.