What purposes do types serve?

[Steven T. Hatton]

I'm carrying on a discussion in a nother context regarding the value and
usefulness of data types. Part of that discussion has to do with how data
types might be implemented in the language specific to that context. I'm
using C++ as an example for comparison and contrast.

I believe I have a pretty go idea how data types work in C++, but I'm not
sure I could enumerate a list of reasons for using types without giving it
a lot of thought. Anybody care to provide their list of reasons for having
data types in C++?

--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/

[Gianni Mariani]

Steven T. Hatton wrote:

I'm carrying on a discussion in a nother context regarding the value and
usefulness of data types. Part of that discussion has to do with how data
types might be implemented in the language specific to that context. I'm
using C++ as an example for comparison and contrast.

I believe I have a pretty go idea how data types work in C++, but I'm not
sure I could enumerate a list of reasons for using types without giving it
a lot of thought. Anybody care to provide their list of reasons for having
data types in C++?

All data has a "type". The question is wether it is known by the
compiler ( "static type" ) and wether the compiler would be able to do
things better.

This is probably not an exhaustive list of "static type" usage.

a) Probably the most important use of types is that the compiler can use
it to create code that runs well (fast) on the target CPU. If you
didn't have any types then all objects would be the same and you would
need to determine type at runtime which can be prohibitibely costly from
a performance perspective. In theory, a dynamically typed system could
generate code at run time (JIT or Just In Time compiler). In practice
there are significant limitations in applicability. No JIT system is as
universally applcable as the more common statically typed compiler
implementations . For example, simple commands like "ls" or "cp" would
need to load a whole VM in Java and by the time the JIT compiler was
loaded it would be time to exit the process. Arguably, the JIT compiler
may produce better code for tight loops, however there is nothing
stopping the JIT process to work on compiled code as well (see valgrind
for example). Enough ranting - at least with the most common
dynamically typed languages today (javascript, php, perl etc), JIT is
not even an option.

b) selection of methods based on type. (function overloading)

c) specialization of code (generic programming based on templates)
Actually the whole idea of templates is that the type is still
determined at compile time but later than "parsing" time. It breaks the
compilation process into 2 logical phases, interpret the meaning of the
source code, generate the specializations needed and then generate the
final machine code. (The template "export" concept breaks that down even
further)

d) Error detection (oops probably ties as most important). One of the
most important things when designing code is that you want to make it so
that programming errors are found as soon as possible. This means that
you want to catch errors like ( apples > oranges ) comparing
incompatible types. In a dynamically typed system you may find these
errors at the most unfortunate time. (I can attest to that - I recently
fixed a bug in PHP where a certain comination of inputs would cause this
to happen - in a statically compiled system, these errors are found
before getting to this ).

Off the top, I can't think of anything else where a "dynamicall y typed"
programming system would be different to a "statically typed"
programming system.

[Howard]

"Steven T. Hatton" <ch********@ger mania.sup> wrote in message
news:js******** *************** *******@speakea sy.net...

I'm carrying on a discussion in a nother context regarding the value and
usefulness of data types. Part of that discussion has to do with how data
types might be implemented in the language specific to that context. I'm
using C++ as an example for comparison and contrast.

I believe I have a pretty go idea how data types work in C++, but I'm not
sure I could enumerate a list of reasons for using types without giving it
a lot of thought. Anybody care to provide their list of reasons for
having
data types in C++?

I assume you mean built-in types? Well, you need at least *one* data type:
the byte (or whatever term you want to specify as the minimum storage unit).
But adding more built-in types allows the code to operate faster, both
because you don't have to spend time reading part of a data item in order to
determine how to interpret the rest of it (as you do in XML, for example),
and also because you can use existing CPU instructions, which have integer,
floating-point, and byte operations (as well as possibly others).

Or perhaps you're referring only to user-defined types? In that case,
they're not actually _needed_ at all. But if you want to work in an
object-oriented language, in order to gain its benefits, then user-defined
data types are obviously required (by the definition of object-oriented).

If you mean why have _any_ data types at all, then I would posit that it's
impossible to present an algorithm which does not, by its very nature,
describe at least one data type (even if only a single "bit", to represent
the simplest, boolean, state).

-Howard