Integer sizes

[David Fisher]

The most common sizes of integer types seem to be:

8 bits - signed char
16 bits - short
16 or 32 bits - int
32 or 64 bits - long

Question #1:

Does anyone know how common sizes other than these are ? I know that the
standard says that number of bits in a "byte" (char) is >= 8, but I have not
come across values other than these yet ...

Question #2:

Is anyone aware of a package that has some portable definitions of things
like Int8, Int16 and Int32 (assuming they are possible for the platform) ?
If not, I think you could do this using the definitions in <limits.h>
(<climits> ?). I am aware that the preprocessor doesn't understand the
sizeof operator, so you can't do it that way.

Thanks,

David F

[Peter van Merkerk]

> >> I work with a C compiler for which, by default, int is 8 bits.

IIRC according to the standard an int should be at least 16 bits. It seems

that your C compiler isn't very standard compliant.
The compiler is compliant, I believe, perhaps because it allows you
to change the meaning of int to 16 bits via a switch.

In that case it is only compliant when you use that switch.
It is a compiler
for PIC microcontroller s, which have 8-bit registers and instructions
only.
That explains something, the PIC processor family has a kinda weird
instruction set. OTOH the cc65 compiler for the 6502 processor (from the
good old days: a true 8-bit processor with no support for 16-bit operations
other than having a carry flag) the int size is 16-bit. But because 16-bit
operations are slow on this processor the compiler documentation recommends
against using int's and recommends use char's instead whenever you can.
I guess most people don't aim to port PIC programs to Posix or
WinXP .. :-)
I guess the PIC compiler doesn't come with a windowing library either :-)
I some cases the target platform is so different from any other platform
that cross-platform compatibility is non-issue anyway.

Personally, I HATE all this business of int, long, long long, double,
double double, and all this incomprehensibl e crap. *And Non-Portable
Crap, I might add*. Most compilers come with headers, I believe,
where they define numeric types more inteligently, like

Yes, it is pain when writing cross-platform code. Unfortunately any
constructs a compiler may have to explicitly specify the size are
non-standard. I would welcome standardization in this area.

I'd like to see something really drastic done about this whole issue,
maybe something like announcing that keywords such as int, long,
short, etc. are to be deprecated and eventually removed from the
language, to encourage change.

Don't hold you breath, I don't see that happen in my life time (I do plan
to be around for another couple of decades)
But for this to happen, something else
must come first: Units.
There's a company that came up with a template library called SIUnits,
which allows you to define classes representing distances, areas,
volumes, weights, densities, pressures, electron densities,
currencies, temperatures, and what not; expressed in various systems
of units. Their system is a bit too complex for my taste, including
physics models for six areas of application, including scientific,
relativistic and non-relativistic...

I'd be happy with a system that just makes sure you don't add
millimiters to inches and divide by celsius to get dollars, if you
know what I mean.

I understand what you mean. You can do that easilly in C++; just make a
classes for millimiters, inches, celcius and dollars and bit of operator
overloading magic. Having done that, if you add millimeters to inches, you
can either choose to get a compile error, or apply the correct conversion
automagically.

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

[Jack Klein]

On Thu, 04 Dec 2003 01:23:36 -0500, Dan W. <da**@raytron-controls.com>
wrote in comp.lang.c++:

[snip]

I work with a C compiler for which, by default, int is 8 bits.
The people who produced it claim that it is a C compiler, but they are
lying, it is not. It is a different language that imitates part of C.
Personally, I HATE all this business of int, long, long long, double,
double double, and all this incomprehensibl e crap. *And Non-Portable
Crap, I might add*. Most compilers come with headers, I believe,
where they define numeric types more inteligently, like

__INT08
__INT16
...
__UINT08
__UINT16

Yes, and other compilers come with libraries that define them as U8,
S16, and so on, or BYTE and UWORD, and so on, and dozens of similar,
but not identical, varieties.

That's the whole point of using the C standard <stdint.h>. They are
probably not the prettiest names for exact width types ever invented,
but they are standard now in C and will be standard in C++.

So you won't have to edit the compiler-specific type names to a
different set of compiler-specific type names each time you port your
code to a different compiler or processor.

Any set of standard names that clearly express what they define is
better than dozens of non-standard names made up independently by each
compiler and library writer.

--
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++ ftp://snurse-l.org/pub/acllc-c++/faq

[Kelsey Bjarnason]

On Thu, 04 Dec 2003 16:10:07 +1100, David Fisher wrote:

The most common sizes of integer types seem to be:

8 bits - signed char
16 bits - short
16 or 32 bits - int
32 or 64 bits - long

Question #1:

Does anyone know how common sizes other than these are ? I know that the
standard says that number of bits in a "byte" (char) is >= 8, but I have not
come across values other than these yet ...

Apparently a lot of embedded systems use char, short, int and long of 32
bits. Some older machines (PDP?) used 9 bit chars (and 36 bit ints, IIRC.)

Simplest solution: use the size guaranteed to have _at least_ as many bits
as you need, but don't assume it'll _only_ have that many.

[Dan W.]

On Thu, 4 Dec 2003 14:51:46 +0100, "Peter van Merkerk"
<me*****@deadsp am.com> wrote:

I understand what you mean. You can do that easilly in C++; just make a
classes for millimiters, inches, celcius and dollars and bit of operator
overloading magic. Having done that, if you add millimeters to inches, you
can either choose to get a compile error, or apply the correct conversion
automagicall y.

Nothing is as easy as first sounds in this business; luckily some
people at boost are taking a crack at it:

http://lists.boost.org/MailArchives/boost/msg29353.php

Here's a link to some attempt at a formal specification:

http://www.servocomm.freeserve.co.uk...ical_quantity/

Cheers!

[Carl Muller]

"David Fisher" <no****@nospam. nospam.nospam> wrote in message news:<3n******* ***********@nas al.pacific.net. au>...

The most common sizes of integer types seem to be:

8 bits - signed char
16 bits - short
16 or 32 bits - int
32 or 64 bits - long

Question #1:

Does anyone know how common sizes other than these are ? I know that the
standard says that number of bits in a "byte" (char) is >= 8, but I have not
come across values other than these yet ...

Well, my current CPU has char=16 bits, short=16 bits, int=16 bits,
long=32 bits (thank goodness).

As for why I'd want to use octets - well, a factor of 2 expansion in
ROM size ain't nice, and also would make the peripherals (sound,
graphics, etc.) behave funny. So the data has to be preprocessed to
join it up into 16 bit chunks.