Proposal: New types in C++0x

[Ioannis Vranos]

Since there is the need of a new 64-bit integer type, the approach taken
should be extensible.

What about introducing int64 being exactly 64 bit, int32 being exactly
32 bits and int16 being exactly 16 bits, and making short and int
equivalent to int16, and long being equivalent to int32?




My proposal more thoroughly:

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.

unsigned long is another name of unsigned int32.


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;

vector<int32> someVector;

list<unsigned int64> someList;


int32 *p = new int32[10];

long *pp = p;


etc.

 

[David Hilsee]

Since there is the need of a new 64-bit integer type, the approach taken
should be extensible.

What about introducing int64 being exactly 64 bit, int32 being exactly
32 bits and int16 being exactly 16 bits, and making short and int
equivalent to int16, and long being equivalent to int32?




My proposal more thoroughly:

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.

unsigned long is another name of unsigned int32.


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;

vector<int32> someVector;

list<unsigned int64> someList;


int32 *p = new int32[10];

long *pp = p;

Wouldn't imposing exact requirements on existing types potentially cause
incompatibility problems? If, for example, there exists a platform that
makes int a 32-bit value (which would include many platforms, I reckon),
then replacing int's representation with a 16 bit representation would break
old programs. I think it's best to define more specific types like int16,
int32, and int64, leave the other types alone, and let programs use the new
types as they are needed. That way, explicit representations are only used
as they are required. I believe this is the approach taken by the new C
standard, but I could be wrong.

 

[Jack Klein]

Since there is the need of a new 64-bit integer type, the approach taken
should be extensible.

What about introducing int64 being exactly 64 bit, int32 being exactly
32 bits and int16 being exactly 16 bits, and making short and int
equivalent to int16, and long being equivalent to int32?

Gee, you are only some 5 years behind the times, since the October,
1999 adoption of ISO 9899:1999 Programming Languages -- C.

Your proposal is actually poorly thought out and harmful. What of
platforms that don't have 16-bit objects at all? There are some, you
know, and C++ compilers for some of them.

My proposal more thoroughly:

int16 is introduced and is an exact 16-bit type (of course additional
padding bits are allowed). int and short become equivalent of it.

If it has padding bits, it is not an exact-width 16-bit type.

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.

This would break an extremely large amount of conforming, if not
strictly portable, code that expects ints to be at least 32 bits.
There are millions of lines of such code in existence in working
programs where portability to 16-bit platforms is not considered
important.

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

On at least some 64-bit processor implementations, (un)signed long
will be 64 bits.

signed int32, int32, signed long, long are all the same.

unsigned long is another name of unsigned int32.


int64 is introduced and holds 64-bit values. signed int64 is equivalent
and unsigned int64 is the unsigned type.

The original 1989 ANSI standard mentioned the already popular
extension 'long long' for an integer type with at least 64 bits. It
has been standardized in C for 5 years, and will be standardized, with
that name, in C++.

Do you actually think that both C and C++ have completely avoided
specifying exact representations for the integer types for 30 plus
years because nobody thought of it before you did? If you want
exactly specified sizes and ranges for all the arithmetic types, you
know where to find Java.

And for a portable and standardized method of providing ways to
specify integer types with various attributes, including such
exact-width types as an implementation can support, do a web search
for "stdint.h", part of standard C.

Finally, the place to propose new features for C++ is in the moderated
group not here. Read the FAQ first, of course.

 

[Peter van Merkerk]

This would break an extremely large amount of conforming, if not
strictly portable, code that expects ints to be at least 32 bits.
There are millions of lines of such code in existence in working
programs where portability to 16-bit platforms is not considered
important.

Also 16-bit ints would slowdown code on many 32-bit platforms. int has
traditionally been the fastest type of at least 16 bits for a given
platform.

 

[Tom Widmer]

Since there is the need of a new 64-bit integer type, the approach taken
should be extensible.

What about introducing int64 being exactly 64 bit, int32 being exactly
32 bits and int16 being exactly 16 bits, and making short and int
equivalent to int16, and long being equivalent to int32?

I just posted this in the moderated group, but here it is again, for
expediency's sake:

http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
(read from page 37 onwards).

Tom

 

[Pete Becker]

Finally, the place to propose new features for C++ is in the moderated
group not here. Read the FAQ first, of course.

He posted it there, as well as on comp.lang.c++.moderated, and got the
same answers he's getting here.

 

[Ioannis Vranos]

http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
(read from page 37 onwards).

Thanks for the very informational link. However long long is not an
extensible name approach, and immediately 128 bit integers come to mind.


So why not use suitable names from now? long64 comes to mind. Eventually
integer types are bound to size, so we had better get used to this.


In any case a longx/intx scheme is better to be chosen.

 

[Victor Bazarov]

[...]
In any case a longx/intx scheme is better to be chosen.

I think we just have to live with the fact that you simply don't\
realise that if it _were_ better, it would have been already in use.

 

[Ioannis Vranos]

I think we just have to live with the fact that you simply don't\
realise that if it _were_ better, it would have been already in use.

Victor being always sincere.

 

[Ioannis Vranos]

I think we just have to live with the fact that you simply don't\
realise that if it _were_ better, it would have been already in use.

However what will happen in the C1x revision when an 128 bit type will
have to be introduced? We will call it long long long or we will have a
new long128 or something and the total types will be


char
short
int
long
long long
long128



Why not "fix" this from now?

 

[Greg Comeau]

However what will happen in the C1x revision when an 128 bit type will
have to be introduced? We will call it long long long or we will have a
new long128 or something and the total types will be


char
short
int
long
long long
long128



Why not "fix" this from now?

Another wrench: What if neither of these is the "fix"?

 

[Ioannis Vranos]

Another wrench: What if neither of these is the "fix"?

OK, I am open to alternatives!

Anything in mind?

 

[scott urban]

However what will happen in the C1x revision when an 128 bit type will
have to be introduced? We will call it long long long or we will have a
new long128 or something and the total types will be

I propose the keyword 'really'. For your hypothetical problem:

long long int b; // >= 64-buts
really long int c; // >= 128-bits
really really long int d; // >= 256-bits
etc

Also, these extensions and overloads:

really short int e; // 4-bits

really really short int f; // 2-bits

really volatile bool b; // a solution for the DCL problem

really mutable int x; // accessing x changes x in random ways

really inline void foo () { ... } // non-optional

int foo (really const int & x); // can't cast away const

class X
{
really private: // disallow access from friends

really virtual void foo (); // instead of = 0 syntax

};


JK, of course. This may be foolish, but I don't for see the need for a
native 128-bit type anytime soon. I hope to be retired before the need
for that kind of address space is even remotely conceivable, and for
other applications (cryptography, calculating pi, whatever) there are
libraries for Bignums.

Scott

 

[Ioannis Vranos]

JK, of course. This may be foolish, but I don't for see the need for a
native 128-bit type anytime soon. I hope to be retired before the need
for that kind of address space is even remotely conceivable, and for
other applications (cryptography, calculating pi, whatever) there are
libraries for Bignums.

Well 128 bit game consoles have been around for a long time

http://www.viewz.com/shoppingguide/consoleguide6.shtml

http://www.worldhistory.com/wiki/1/128-bit-era.htm


so I guess in those machines there is definitely an 128 bit type.



I do not think that bits are only convenient for addressing memory but
also for providing larger numbers and more accuracy.