Storing an integer: why "int"?

[JKop]

When you want to store an integer in C++, you use an integral type, eg.

int main()
{
unsigned char amount_legs_dog = 4;
}

In writing portable C++ code, there should be only two factors that
influence which integral type you choose:

A) Signedness. Do you want only positive values? Or do you want both
positive and negative values?

B) The minimum range for that type as specified by the C++ Standard.
The minimum range for "short" and "int" are identical. The following
statement is always true on all implementations :

sizeof(short) <= sizeof(int)

As this is so, why would one ever use the type "int" at all? It seem to have
no merit whatsoever. I will always use "short" in its place.

Any thoughts on this?

-JKop

[John Harrison]

On Tue, 03 Aug 2004 19:59:03 GMT, JKop <NU**@NULL.NULL > wrote:

When you want to store an integer in C++, you use an integral type, eg.

int main()
{
unsigned char amount_legs_dog = 4;
}

In writing portable C++ code, there should be only two factors that
influence which integral type you choose:

A) Signedness. Do you want only positive values? Or do you want both
positive and negative values?

B) The minimum range for that type as specified by the C++ Standard.
The minimum range for "short" and "int" are identical. The following
statement is always true on all implementations :

sizeof(short) <= sizeof(int)

As this is so, why would one ever use the type "int" at all? It seem to
have
no merit whatsoever. I will always use "short" in its place.

Any thoughts on this?

-JKop

The standard says something to the effect of 'int shall be the natural
size for the architecture used'. In other words if you are on a 32 bit
machine you can reasonably expect an integer to be 32 bits instead of the
16 guaranteed by the standard.

Also (although I'm no expert) if you are on an architecture where int and
short are different sizes its quite reasonable to expect int to be more
efficient than short since it uses the natural size of the architecture.
In other words use short if you want to save space but otherwise use int,
it might be better but it won't be worse (except at saving space).

john

[JKop]

John Harrison posted:

On Tue, 03 Aug 2004 19:59:03 GMT, JKop <NU**@NULL.NULL > wrote:

When you want to store an integer in C++, you use an integral type, eg.

int main()
{
unsigned char amount_legs_dog = 4; }

In writing portable C++ code, there should be only two factors that influence which integral type you choose:

A) Signedness. Do you want only positive values? Or do you want both positive and negative values?

B) The minimum range for that type as specified by the C++ Standard.

The minimum range for "short" and "int" are identical. The following statement is always true on all implementations :

sizeof(short) <= sizeof(int)

As this is so, why would one ever use the type "int" at all? It seem to have no merit whatsoever. I will always use "short" in its place.
Any thoughts on this?

-JKop
The standard says something to the effect of 'int shall

be the natural size for the architecture used'. In other words if you are on a 32 bit machine you can reasonably expect an integer to be 32 bits instead of the 16 guaranteed by the standard.

Also (although I'm no expert) if you are on an architecture where int and short are different sizes its quite reasonable to expect int to be more efficient than short since it uses the natural size of the architecture. In other words use short if you want to save space but otherwise use int, it might be better but it won't be worse (except at saving space).

john

But again I want to stress that we're writing portable
code. In writing portable code, one's decision on which
integral type to use should be based solely upon:

a) Signedness

b) The minimum range

From this, (again writing portable code), "int" appears to
have no merit whatsoever, and it seems that one should
always use "short" in its place.
-JKop

[Julián Albo]

JKop wrote:

But again I want to stress that we're writing portable
code. In writing portable code, one's decision on which
integral type to use should be based solely upon:
a) Signedness
b) The minimum range

Why solely? The code is not less portable if you take other things into
account.

--
Salu2

[Andre Kostur]

JKop <NU**@NULL.NULL > wrote in news:Pn******** **********@news .indigo.ie:

But again I want to stress that we're writing portable
code. In writing portable code, one's decision on which
integral type to use should be based solely upon:

a) Signedness

b) The minimum range

From this, (again writing portable code), "int" appears to
have no merit whatsoever, and it seems that one should
always use "short" in its place.

By your own argument, there is no merit to using a short vs. an int.
Specifically:

a) Signedness - Both int and short have the same sign (as does unsigned
int, and unsigned short)

b) The minimum range - short's minimum is <= int's minimum. Thus anything
you can store in a short is going to fit in an int

c) Word alignment - int is supposed to be the natural word length for the
platform, short has no such suggestion. Thus you have the possibility of a
more efficient (run-time) program.

So on the two points you mention, there is no benefit to using a short vs.
an int, and adding the third point tips the scales in favour of int.

However, I don't agree with the basic premise upon which your argument is
based. I belive that there are other concerns.

[Spacen Jasset]

"JKop" <NU**@NULL.NULL > wrote in message
news:Pn******** **********@news .indigo.ie...

John Harrison posted:

On Tue, 03 Aug 2004 19:59:03 GMT, JKop <NU**@NULL.NULL >

wrote:

When you want to store an integer in C++, you use an integral type, eg.

int main()
{
unsigned char amount_legs_dog = 4; }

In writing portable C++ code, there should be only two factors that influence which integral type you choose:

A) Signedness. Do you want only positive values? Or do you want both positive and negative values?

B) The minimum range for that type as specified by the C++ Standard.

The minimum range for "short" and "int" are identical. The following statement is always true on all implementations :

sizeof(short) <= sizeof(int)

As this is so, why would one ever use the type "int" at all? It seem to have no merit whatsoever. I will always use "short" in its place.
Any thoughts on this?

-JKop

The standard says something to the effect of 'int shall

be the natural

size for the architecture used'. In other words if you

are on a 32 bit

machine you can reasonably expect an integer to be 32

bits instead of

the 16 guaranteed by the standard.

Also (although I'm no expert) if you are on an

architecture where int

and short are different sizes its quite reasonable to

expect int to be

more efficient than short since it uses the natural

size of the

architecture. In other words use short if you want to

save space but

otherwise use int, it might be better but it won't be

worse (except at

saving space).

john

But again I want to stress that we're writing portable
code. In writing portable code, one's decision on which
integral type to use should be based solely upon:

a) Signedness

b) The minimum range

From this, (again writing portable code), "int" appears to
have no merit whatsoever, and it seems that one should
always use "short" in its place.
-JKop

I see what your thinking. But if you want *at least 16 bits* but fast, then
you should probably use an int. Only where you require exactly 16 bits --
use a short -- this isn't guaranteed anyway but often it's used behind
typedefs i.e. typedef unsigned short U16; to get a "exact" 16 bit sized
value. Shorts can ofcourse be bigger than 16 bits though, hence the need for
the typedef, and the hope that machine accessible sizes are available to
support a 16 bit type;
One use for an exact 16 bit size is to represent UTF16 a 16 it unicode
encoding. Using more than 16 bits to represent UTF16 may cause difficulty
and require more work.

This whole thing of differing word size is a thorny issue and there appears
to be much sense in having fixed sizes, like in java, considering the
trouble it causes and the care that must be taken.

[Aguilar, James]

"JKop" <NU**@NULL.NULL > wrote in message
news:Pn******** **********@news .indigo.ie...

But again I want to stress that we're writing portable
code. In writing portable code, one's decision on which
integral type to use should be based solely upon:

a) Signedness

b) The minimum range

From this, (again writing portable code), "int" appears to
have no merit whatsoever, and it seems that one should
always use "short" in its place.

From the fact that int is the suggested to be the natural length for any
architecture, isn't it true that int will be portably faster?

Also, why should those two characteristics be the deciding factor of what
type you use? Is there a rule somewhere that says you must use the minimum
amount of storage possible? I don't recall that being anywhere in the
standard either . . . what if C++ is eventually implemented on a machine
that runs more quickly when it has less free memory?

In any case, code that uses int as its integral type is no less portable
than code that doesn't, and it's likely to be far faster. There is a limit
to how far lofty ideals (portability, anarchy, communism, optimism, et al)
can be applied to real life.

[Jack Klein]

On Tue, 03 Aug 2004 19:59:03 GMT, JKop <NU**@NULL.NULL > wrote in
comp.lang.c++:

When you want to store an integer in C++, you use an integral type, eg.

int main()
{
unsigned char amount_legs_dog = 4;
}

In writing portable C++ code, there should be only two factors that
influence which integral type you choose:

A) Signedness. Do you want only positive values? Or do you want both
positive and negative values?

B) The minimum range for that type as specified by the C++ Standard.
The minimum range for "short" and "int" are identical. The following
statement is always true on all implementations :

sizeof(short) <= sizeof(int)

As this is so, why would one ever use the type "int" at all? It seem to have
no merit whatsoever. I will always use "short" in its place.
You will be making a big mistake if you do. In the first place, on
many current 32 bit processors, accessing shorts in memory is slower
and/or takes more code. Not only on common platforms like x86, but
popular embedded processors like ARM.
Any thoughts on this?

The real problem is the subtle "gotcha" hiding inside the "usual
arithmetic conversions", originally defined by the first C ANSI/ISO
standard, inherited by C++.

unsigned short us = 3;
signed short ss = -1;

/* other code that doesn't change value of ss or us */

if (ss < us)
{
/* do something */
}
else
{
/* do something else */
}

Now which block, the if or the else, is executed? There are two
possible implementation-defined results, both of them perfectly legal
and correct C++.

If short and int share the same range and representation, the "usual
arithmetic conversions" state that they are ss and us must be
converted to unsigned int, because signed int cannot hold all possible
values of the unsigned short type. That causes us to be converted to
(unsigned int)3, and ss to be converted to (unsigned int)-1, the
latter resulting in UINT_MAX. The conditional will be false and the
else branch executed.

On the other hand, on a common desk top implementation where short has
a narrower range of values than int, both us and ss will be converted
to signed ints, -1 is less than 3, and the if branch executed.

Google for "stdint.h", a header added to C in the 1999 C standard
update. This will almost certainly become a part of the next C++
standard update, preferably as <cstdint>. It provides a very flexible
way of using the platform's optimum integer type for specific
purposes.

--
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.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[JKop]

Andre Kostur posted:

JKop <NU**@NULL.NULL > wrote in
news:Pn******** **********@news .indigo.ie:

But again I want to stress that we're writing portable
code. In writing portable code, one's decision on which
integral type to use should be based solely upon:

a) Signedness

b) The minimum range

From this, (again writing portable code), "int" appears to
have no merit whatsoever, and it seems that one should always use
"short" in its place.
By your own argument, there is no merit to using a short vs. an int.
Specifically:

a) Signedness - Both int and short have the same sign (as does unsigned
int, and unsigned short)

b) The minimum range - short's minimum is <= int's minimum. Thus
anything you can store in a short is going to fit in an int

But an "int" may possibly use more memory.
c) Word alignment - int is supposed to be the natural word length for
the platform, short has no such suggestion. Thus you have the
possibility of a more efficient (run-time) program.

So on the two points you mention, there is no benefit to using a short
vs. an int, and adding the third point tips the scales in favour of
int.
Apart ofcourse from the "int" possibly using more memory.

However, I don't agree with the basic premise upon which your argument
is based. I belive that there are other concerns.

They way I look at it is that there's many integral types provided in C++.
The only difference between them in signedness and range. As such, one's
decision on which to choose can only be based upon those two factors.
-JKop

[JKop]

Jack Klein posted:

On Tue, 03 Aug 2004 19:59:03 GMT, JKop <NU**@NULL.NULL > wrote in comp.lang.c++:

When you want to store an integer in C++, you use an integral type, eg.

int main()
{
unsigned char amount_legs_dog = 4; }

In writing portable C++ code, there should be only two factors that influence which integral type you choose:

A) Signedness. Do you want only positive values? Or do you want both positive and negative values?

B) The minimum range for that type as specified by the C++ Standard.

The minimum range for "short" and "int" are identical. The following statement is always true on all implementations :

sizeof(short) <= sizeof(int)

As this is so, why would one ever use the type "int" at all? It seem to have no merit whatsoever. I will always use "short"

in its place.
You will be making a big mistake if you do. In the first place, on many current 32 bit processors, accessing shorts in memory is slower and/or takes more code. Not only on common platforms like x86, but popular embedded processors like ARM.

Any thoughts on this?
The real problem is the subtle "gotcha" hiding inside

the "usual arithmetic conversions", originally defined by the first C ANSI/ISO standard, inherited by C++.

unsigned short us = 3;
signed short ss = -1;

/* other code that doesn't change value of ss or us */
if (ss < us)
{
/* do something */
}
else
{
/* do something else */
}

Now which block, the if or the else, is executed? There are two possible implementation-defined results, both of them perfectly legal and correct C++.

If short and int share the same range and representation, the "usual arithmetic conversions" state that they are ss and us must be converted to unsigned int, because signed int cannot hold all possible values of the unsigned short type. That causes us to be converted to (unsigned int)3, and ss to be converted to (unsigned int)-1, the latter resulting in UINT_MAX. The conditional will be false and the else branch executed.

On the other hand, on a common desk top implementation where short has a narrower range of values than int, both us and ss will be converted to signed ints, -1 is less than 3, and the if branch executed.
Google for "stdint.h", a header added to C in the 1999 C standard update. This will almost certainly become a part of the next C++ standard update, preferably as <cstdint>. It provides a very flexible way of using the platform's optimum integer type for specific purposes.

So then your argument would suggest never use "short",
always use "int" in its place as it's faster.

So it looks like, if you're writing a program for:

a) Speed: Then use "int"

b) Optimal memory usage: Then use "short"

But then we're left with: Which should we *typically* use?
BTW, what does it mean to say that a system is 32-Bit?
-JKop