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

[JKop]

jeffc posted:

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

Because it can be.
-JKop

[Julián Albo]

JKop wrote:

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.

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

"Memory" was not between the factors you mentioned. Then, acording to your
criteria, are you writing non portable code?

--
Salu2

[Andre Kostur]

no****@nowhere. com wrote in news:411105e7$0 $65601$a1866201
@newsreader.vis i.com:

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

Don't count on it. I know at least one compiler that changes the size of
an unsigned long from 32-bit to 64-bit when it's working on a 64-bit
platform.... (checking... it happened to keep int at 32-bit though)

[Keith H Duggar]

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

My experience as an engineer and researcher is quite the opposite.
There are hundreds of specific examples I could give and dozens of
general categories of computation that involve integers and all are
very common. To name just a very small number of these

computer graphics algorithms, computer gamming, cryptography,
combinatorial algorithms, integer programming, finite element
analysis, theorem proving, etc.

In fact the computer gaming industry alone is about a $20 billion a
year business and it is almost exclusively integer based. Add to that
multi-billion dollar special affects industry which is again dominated
by integer algorithms.

So with due deference, I don't see how integer computation could be
called "relatively rare".

Keith

[Uwe Schnitker]

"Andrew Koenig" <ar*@acm.org> wrote in message news:<WS******* **************@ bgtnsc05-news.ops.worldn et.att.net>...

"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:

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

I find your distinction between using integers for counting vs. using
integers for computation very interesting. It could help with writing
consistent and idiomatic C++ code, IMHO.

For counting usage of integers, choosing an unsigned type - and
preferably a library-defined one - is a fairly straightforward policy.

One might also consider a policy of always choosing a signed integer
type whenever the integer is used for computation, since computations
may now or in the future involve negative values, especially if you
consider computing differences, and mixed signed/unsigned arithmetic
is somewhat fragile.

Is this a sensible policy, too?

Hmmm, sometimes you combine counting and computation, e.g. with some
kind of index calculation. Of course, this kind of calculation tends
to be what perl programmers call "synthetic code", that should be
avoided or at least abstracted away, but sometimes you have to bite
the bullet.

Any thoughts on that?

Uwe

[Karl Heinz Buchegger]

JKop wrote:

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

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

Right.
But still: you may pay this memory savings with increased
runtime when accessing the memory.

And: Hand to the heart. In todays desktop environments, is
it really a big deal to spend a few 100 bytes? Every
no name PC from a noname discounter comes with more memory
then an entire computing center had 20 years ago.

There may be good reasons why using short is a good idea, most
of them turn around memory savings in limited environments. But
with so many others things in programming: There is seldome a 100%
rule. Using always short instead of int is such a thing. There
are uses, no doubt, but in general simply use the most natural
data type for your platform. And that is int.

--
Karl Heinz Buchegger
kb******@gascad .at

[Rob Williscroft]

Uwe Schnitker wrote in news:30381f67.0 408042254.3397c d90
@posting.google .com in comp.lang.c++:

One might also consider a policy of always choosing a signed integer
type whenever the integer is used for computation, since computations
may now or in the future involve negative values, especially if you
consider computing differences, and mixed signed/unsigned arithmetic
is somewhat fragile.

Unfortunatly C++ doesn't tell us *all* the characteristics of the
signed types, there could be a trap value, what happens on overflow
etc. With unsigned everything (except the size/range) is well defined.

Also using unsigned for everything sidesteps the mixed signed/unsigned
problem :).
Is this a sensible policy, too?

Yes (except when it isn't :).

C++ need's integer type's with well defined characteristics ,
Here's my attempt at a solution for unsigned:

http://www.victim-prime.dsl.pipex.co...int/index.html

I must get around to writing signed_int<> sometime.

Rob.
--
http://www.victim-prime.dsl.pipex.com/

[Jukka Lehtonen]

Karl Heinz Buchegger <kb******@gasca d.at> writes:

There may be good reasons why using short is a good idea, most
of them turn around memory savings in limited environments. But
with so many others things in programming: There is seldome a 100%
rule. Using always short instead of int is such a thing. There
are uses, no doubt, but in general simply use the most natural
data type for your platform. And that is int.

One example comes to mind. Graphics. The memory is not a limit either
on main RAM or the graphics card side, but the bandwith of copy from
one location to the other is. Say, an array of million triangles.
Each triangle may have at most three unique vertices and each vertex
has position (xyz, float), normal (xyz, can be short), color (rgba,
can be short) and maybe texture coordinates as well. That is more than
few 100 values. And the GPU may prefer shorts.

Thus, I must agree:
use the natural data type of the platform, and know your platform.

JVL
--
Be reading you.

mailto:Ju****** ******@abo.fi

[jeffc]

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

Whoa, if the sign is "less than or equal to", then why

are you acting

like it's "less than"?

Because it can be.

If it "can be", then why are you acting like "it is".

[JKop]

jeffc posted:

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

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

Because it can be.

If it "can be", then why are you acting like "it is".

The same reason why fire-men are still on duty when
there's no fires around.

-JKop