From Newsgroup: comp.compilers

"marb...@yahoo.co.uk" <marblypup@yahoo.co.uk> writes:

From nearly 40 years
of C programming, I've concluded that having "int" be the "natural" size of >integer is more of a liability than an asset.)

I have also been programming in C, but also in Forth since the 1980s.
C has the well-known integer type zoo, but evolved from B, which had
only a single type (the machine word, which became "int" in C). On
the integer side Forth has only cells (machine words) and
double-cells, and, in memory, characters (bytes), which are loaded and processed as cells (like chars in C are promoted to ints).

My experience is that portability bugs are very rare in Forth code,
while they are much more common in C code.

Not only is there a zoo of integer types in C, there are also
additional integer types (off_t, uid_t, time_t, etc.) that are mapped
to different more basic integer types on different platforms; and
there are library functions like printf(), abs/labs/llabs() etc. where
you have to decide on one of a few integer types, but if the type at
hand is not among them, you need to use some cumbersome non-C
machinery like configure to select the code.

By contrast, in Forth most integers are passed as cells. When you pass
it as double-cell, you also pass it on a different platform (with
different cell width) as double-cell, so once you debug the program on
one machine, it almost always works on a machine with a different cell
size.

However, there is one discipline you have to observe: For address
computations you have to use the cell-size-agnostic scaling word CELLS
rather than making use of the knowledge of the cell size on the
platform you are testing on (Forth code from the 16-bit era, before
CELLS was introduced, uses 2* instead, and is not portable to systems
with wider cells).

- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/
--- Synchronet 3.21b-Linux NewsLink 1.2