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

[Gernot Frisch]

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

int is always at least as fast as short. Good compilers can optimize
your code immensly if you use int, since int is the bus width of the
processor you are targeting for.
The old DOS (until 6.x) was a 16 bit system. Windows 3.x was, too. So
an int was (propably - depending on your compiler) 16 bits (=short).
Nowadays it's 32 bits, but the 64 bit processor families are there and
new OSes will propably have compilers that define int to 64 bits,
since the processor can handle them faster than 32 bits.
Memory efficiency is not the smaller the better, since small memory
addresses might take longer to address than e.g. 32 bit aligned
addresses. I'm not sure and if I'm wrong, flame grill me.

Anyway, use short if you have a very large set of them and use long
where you need longer values. I don't use int at all, for exaclty this
reason - I want to know the size of my variables, not the "minimum"
size of them.
Just my .02$
-Gernot

[Karl Heinz Buchegger]

JKop wrote:

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.

But usually you don't safe much memory by using short throughout
the program. The reason is: alignement.

If the compiler sees to consecutive short's, it may insert some
padding bytes between them to satisfy alignement requirements.

struct UseShort
{
short int A;
short int B;
};

struct UseInt
{
int A;
int B;
};

In most systems, even if sizeof(short) != sizeof(int), it will
happen that sizeof( UseShort ) == sizeof( UseInt ), because the
compiler inserted some extra bytes after UseShort::A to bring
UseShort::B onto an address which satisfies the alignement.

Since int represents is the 'natural' data type of a specific
architecture, it is safe to assume that it also fullfills the
alignment requirements without a need for padding bytes.

So in theory you are right: short may use less memory. But
you pay this price with more wasted memory due to padding.

PS: Of course most compilers allow you to change the alignement
by means of some pragma or compiler option. Usually you pay
for this by increased run time. There are eg. CPU's where eg memory
access *has to be* on an even address or else the CPU generates
an exception. A operating system function then kicks in, restarts
the load, but this time at a correctly aligned address, and uses
register manipulation to fetch the bytes you want.
--
Karl Heinz Buchegger
kb******@gascad .at

[jeffc]

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

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.

Whoa, if the sign is "less than or equal to", then why are you acting like
it's "less than"?

[Peter van Merkerk]

Karl Heinz Buchegger wrote:

JKop wrote:

Andre Kostur posted:

JKop <NU**@NULL.NULL > wrote in
news:Pn***** *************@n ews.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.

But usually you don't safe much memory by using short throughout
the program. The reason is: alignement.

If the compiler sees to consecutive short's, it may insert some
padding bytes between them to satisfy alignement requirements.

struct UseShort
{
short int A;
short int B;
};

struct UseInt
{
int A;
int B;
};

In most systems, even if sizeof(short) != sizeof(int), it will
happen that sizeof( UseShort ) == sizeof( UseInt ), because the
compiler inserted some extra bytes after UseShort::A to bring
UseShort::B onto an address which satisfies the alignement.

Since int represents is the 'natural' data type of a specific
architecture, it is safe to assume that it also fullfills the
alignment requirements without a need for padding bytes.

So in theory you are right: short may use less memory. But
you pay this price with more wasted memory due to padding.

PS: Of course most compilers allow you to change the alignement
by means of some pragma or compiler option. Usually you pay
for this by increased run time. There are eg. CPU's where eg memory
access *has to be* on an even address or else the CPU generates
an exception. A operating system function then kicks in, restarts
the load, but this time at a correctly aligned address, and uses
register manipulation to fetch the bytes you want.

On x86 processors in 32-bit mode (e.g. Linux or MS-Windows on a PC),
instructions operating on 16-bit values need a prefix code. In other
words when working with 16-bit values the code becomes larger and slower.

--
Peter van Merkerk
peter.van.merke rk(at)dse.nl

[Andrew Koenig]

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

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?

This analysis is correct as far as it goes, but it doesn't go very far.

What it leaves out is the question of *why* you are using integral types in
the first place.

In my experience, almost all uses of integral types fall into two
categories:

1) Counting
2) Computation

If you are using an integral type for counting, you should probably be using
an unsigned type. Beyond that, the correct type to use depends on what you
are counting.

If you are counting elements of a data structure from the standard library,
you should be using that data structure's size_type member. So, for
example, if you wish to represent an index in a vector<string>, you should
not use int, short, or the unsigned variants thereof. Instead, you should
use vector<string>: :size_type. If you want to deal with the difference
between two vector<string> indices, which therefore might be negative, use
vector<string>: :difference_typ e.

If you are counting elements of a built-in array, or another data structure
that will fit in memory, you should use size_t. If you need a number
commensurate with the size of memory that might be negative, use ptrdiff_t.

In short, if you are counting, you should usually not use the built-in types
directly.

Now, what about computation? Most of the time, you should be using long or
unsigned long unless you have a reason to do otherwise. After all, that's
the only way that you're assured of not being limited to 16 bits.

My experience is that integer computation is actually relatively rare. Most
of the time, integers are used for counting, and in that context, it is
better to use the library-defined synonyms for the integral types than it is
to use those types directly.

[Andre Kostur]

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

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.

Possibly... but mimimum memory usage wasn't in your list of criteria.
And as someone else has pointed out (Karl), whatever memory savings you
thought you had, may be consumed by the compiler anyway in order to word-
align your variables (which int's already are).

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.

Again, not in your list of criteria.

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.

So by your own statement, you consider run-time efficiency, or memory
footprint to be completely irrelevant considerations. Interesting, since
as far as I know, both of these criteria are _very_ important criteria to
professional programmers (as to which is more important, it depends on
various constraints that the programmer may have to work in...)

[nospam]

Gernot Frisch <[e-mail] > wrote:

int is always at least as fast as short. Good compilers can optimize
your code immensly if you use int, since int is the bus width of the
processor you are targeting for.
The old DOS (until 6.x) was a 16 bit system. Windows 3.x was, too. So
an int was (propably - depending on your compiler) 16 bits (=short).
Nowadays it's 32 bits, but the 64 bit processor families are there and
new OSes will propably have compilers that define int to 64 bits,
since the processor can handle them faster than 32 bits.

I would guess that most compilers will keep int at 32 bits in order to
break as little code as possible (code that incorrectly assumed the
size of int).

[Julián Albo]

no****@nowhere. com wrote:

I would guess that most compilers will keep int at 32 bits in order to
break as little code as possible (code that incorrectly assumed the
size of int).

Many people used to think the same thing in the 16 bit era...

--
Salu2

[JKop]

Karl Heinz Buchegger posted:

JKop wrote:

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.
But usually you don't safe much memory by using short

throughout the program. The reason is: alignement.

If the compiler sees to consecutive short's, it may insert some padding bytes between them to satisfy alignement requirements.
struct UseShort
{
short int A;
short int B;
};

struct UseInt
{
int A;
int B;
};

In most systems, even if sizeof(short) != sizeof(int), it will happen that sizeof( UseShort ) == sizeof( UseInt ), because the compiler inserted some extra bytes after UseShort::A to bring UseShort::B onto an address which satisfies the alignement.
Since int represents is the 'natural' data type of a specific architecture, it is safe to assume that it also fullfills the alignment requirements without a need for padding bytes.

So in theory you are right: short may use less memory. But you pay this price with more wasted memory due to padding.
PS: Of course most compilers allow you to change the alignement by means of some pragma or compiler option. Usually you pay for this by increased run time. There are eg. CPU's where eg memory access *has to be* on an even address or else the CPU generates an exception. A operating system function then kicks in, restarts the load, but this time at a correctly aligned address, and uses register manipulation to fetch the bytes you want.

Well if sizeof(short) < sizeof(int), then

sizeof(short[49]) < sizeof(int[49]) as they'll be no
padding.
-JKop

[JKop]

Andre Kostur posted:

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

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.
Possibly... but mimimum memory usage wasn't in your list

of criteria. And as someone else has pointed out (Karl), whatever memory savings you thought you had, may be consumed by the compiler anyway in order to word- align your variables (which int's already are).

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.
Again, not in your list of criteria.
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.

So by your own statement, you consider run-time

efficiency, or memory footprint to be completely irrelevant considerations. Interesting, since as far as I know, both of these criteria are _very_ important criteria to professional programmers (as to which is more important, it depends on various constraints that the programmer may have to work in...)

memory was in fact in my criteria. The reason I pick the
smallest integral type with sufficent range is because
it's the one that uses the least memory and has sufficent
range.

-JKop