Storing an integer: why "int"?

[JKop]

jeffc posted:

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

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

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?

 

[Andre Kostur]

(e-mail address removed) wrote in @newsreader.visi.com:

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]

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.

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]

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.

 

[Rob Williscroft]

Uwe Schnitker wrote in @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.com/docs/unsigned_int/index.html

I must get around to writing signed_int<> sometime.

Rob.

 

[Jukka Lehtonen]

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

 

[jeffc]

Because it can be.

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

 

[JKop]

jeffc posted:

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

 

[jeffc]

jeffc posted:


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

But if you'll notice, they don't act like there's a fire.