Types

[jacob navia]

Hi people
I have been working again in my tutorial, and I have finished the
"types" chapter. If you feel like "jacob bashing" this is the
occasion! I am asking for criticisms, or for things I may have said
wrong. Keep in mind that this is a tutorial, and I donot want to
overwhelm the reader with little details.

-------------------------------------------------------------------------*

Types

A machine has no concept of type, everything is just a sequence of bits,
and any operation with those sequences can be done, even if it is not
meaningful at all, for example adding two addresses, or multiplying two
character strings.

A high level programming language however, enforces the concept of types
of data. Operations are allowed between compatible types and not between
any data whatsoever. It is possible to add two integers, or an integer
and a floating point number, and even an integer and a complex number.
It is not possible to add an integer to a function or to a character
string, the operation has no meaning for those types.

An operation implies always compatible types netween the operands.
In C, all data must be associated with a specific type before it can be
used. All variables must be declared to be of a known type before any
operation with them is attempted since to be able to generate code the
compiler must know the type of each operand.

C allows the programmer to define new types based on the previously
dfined ones. This means that the type system in C is static, i.e. known
at compile time, but extensible since you can add new types.

This is in contrast to dynamic typing, where no declarations are needed
since the language associates types and data during the run time.
Dynamic typing is much more flexible, but this flexibility has a price:
the run time system must constantly check the types of the operands for
each operation to see if they are compatible, what slows down the
program considerably.

In C there is absolutely no run time checking in most operations, since
the compiler is able to check everything during the compilation, what
accelerates execution of the program, and allows the compiler to
discover a lot of errors during the compilation instead of crashing at
run time when an operation with incompatible types is attempted.
What is a type?

A first tentative, definition for what a type is, could be “a type is a
definition of an algorithm for understanding a sequence of storage
bits”. It gives the meaning of the data stored in memory. If we say that
the object a is an int, it means that the bits stored at that location
are to be understood as a natural number that is built by consecutive
additions of powers of two. If we say that the type of a is a double, it
means that the bits are to be understood as the IEEE 754 standard
sequences of bits representing a double precision floating point value.
Functions have a type too. The type of a function is determined by the
type of its return value, and all its arguments. The type of a function
is its interface with the outside world: its inputs (arguments) and its
outputs (return value).

Types in C can be incomplete, i.e. they can exist as types but nothing
is known about them, neither their size nor their bit-layout. They are
useful for encapsulating data into entities that are known only to
certain parts of the program.

Each type can have an associated pointer type: for int we have int
pointer, for double we have double pointer, etc. We can have also
pointers that point to an unspecified object. They are written as void
*, i.e. pointers to void. Some types exist only as pointers: the
function pointer type has no object counterpart since a function object
doesn’t exist in C, only pointers to functions exist.

Types classification

This type classification is based on the classification published by
Plauger and Brody, slightly modified.
Types
1. Function types
1.1 Fully qualified function types. (Functions whose full prototype is
visible)
1.2 Assumed function types (Functions whose prototype is partly or not
visible)
1.2.1 Functions whose return value is visible but not their arguments
1.2.2 Functions where the return value and their arguments are unknown.
2. Incomplete types (Types not completely specified)
2.1 void
2.2 Incomplete struct types
2.3 Incomplete array types
2.4 Incomplete union types
3. Object types
3.1 Scalar types
3.1.1 Arithmetic types
3.1.1.1 Integer types
3.1.1.1.1 Specific integer types
3.1.1.1.1.1 char (signed/unsigned)
3.1.1.1.1.2 short (signed unsigned)
3.1.1.1.1.3 int (signed/unsigned)
3.1.1.1.1.4 long (signed/unsigned)
3.1.1.1.1.5 long long (signed/unsigned)
3.1.1.1.2 Bitfields (signed/unsigned)
3.1.1.1.3 Enumeration types
3.1.1.2 Floating types
3.1.1.2.1 float
3.1.1.2.2 double
3.1.1.2.3 long double
3.1.2 Pointer types
3.1.2.1 Pointer to function
3.1.2.2 Pointer to object types
3.1.2.3 Pointer to incomplete types
3.2 Non -scalar types
3.2.1 Struct types
3.2.2 Union types
3.2.3 Array types

Integer types

The language doesn’t specify exactly how big each integer type must be,
but it has some requirements as to the minimum size of the integer
types. The char type must be at least 8 bits, the int type must be at
least 16 bits, and the long type must be at least 32 bits. How big each
integer type actually is, is defined in the standard header limits.h.

Floating types

Floating types are discussed in more detail later. Here we will just
retain that they can represent integer and non integer quantities, and
in general, their dynamic range is bigger that integers of the same
size. They have two parts: a mantissa and an exponent.
As a result, there are some values that can’t be expressed in floating
point, for instance 1/3 or 1/10. This comes as a surprise for many
people, so it is better to underscore this fact here. More explanations
for this later on.
Floating point arithmetic is approximative, and many mathematical laws
that we take for granted like a+b is equal to b+a do not apply in many
cases to floating point math.

Compatible types

There are types that share the same underlying representation. For
instance, in lcc-win32 for the Intel platform, in 32 bits, long and int
are the same. They are compatible types for that version of lcc. In the
version of lcc-linux for 64 bits however, long is 64 bits and int is 32
bits, they are no longer compatible types, but long is now compatible
with the long long type.
Plauger and Brody give the following definition for when two types are
compatible types:
Both types are the same.
Both are pointer types, with the same type qualifiers, that point to
compatible types.
Both are array types whose elements have compatible types. If both
specify repetition counts, the repetition counts are equal.
Both are function types whose return types are compatible. If both
specify types for their parameters, both declare the same number of
parameters (including ellipses) and the types of corresponding
parameters are compatible. Otherwise, at least one does not specify
types for its parameters. If the other specifies types for its
parameters, it specifies only a fixed number of parameters and does not
specify parameters of type float or of any integer types that change
when promoted.
Both are structure, union, or enumeration types that are declared in
different translation units with the same member names. Structure
members are declared in the same order. Structure and union members
whose names match are declared with compatible types. Enumeration
constants whose names match have the same values.

Incomplete types

An incomplete type is missing some part of the declaration. For instance

struct SomeType;

We know now that “SomeType” is a struct, but since the contents aren’t
specified, we can’t use directly that type. The use of this is precisely
to avoid using the type: encapsulation. Many times you want to publish
some interface but you do not want people using the structure,
allocating a structure, or doing anything else but pass those structure
to your functions. In those situations, an opaque type is a good thing
to have.

Casting

The programmer can at any time change the type associated with a piece
of data by making a “cast” operation. For instance if you have:
float f = 67.8f;
you can do
double d = (double)f;
The “(double)” means that the type of data in f should be converted into
an equvalent data using the double representation. We will come back to
types when we speak again about casts later.

[Bob Martin]

in 710422 20061215 084430 av <[e-mail] e:

>who is bwk? is bwk==Brian Kernighan?
the quote above is not valid at last for Who create the Universe
and possibly for many others

The only thing off-topic here is your attempt to bring religion into it.

[CBFalconer]

Chris Dollin wrote:

av wrote:

>Mark McIntyre wrote:

>>>--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

this signature is OT, false and it irritate me: can you please change
it?

(a) It's a /signature/. It's topicality isn't at issue. Feel free to
complain about my signature(s) if you like.

(b) I certainly find debugging code harder than writing it. So it's
certainly not obviously false.

(c) It's a /signature/, not a peer-reviewed essay. It's pithy and
makes a point.

(d) If it irritates you, ignore it. Or introspect to find out why.

(e) It's a /signature/. It's not insulting, it's not offensive,
and it's relevant to programming and tells us something about
the mindset of one of the people most involved with C. I
think it's rather good, myself.

av is a pure Troll. Ignore it. Don't feed it. PLONK it.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

[Random832]

2006-12-13 <l1************ *************** *****@4ax.com>,
av wrote:

On Wed, 13 Dec 2006 12:01:15 +0000, Mark McIntyre wrote:

>>--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

this signature is OT, false and it irritate me: can you please change
it?

How's it false? Did Kernighan not actually say it?

[Random832]

2006-12-15 <el**********@m urdoch.hpl.hp.c om>,
Chris Dollin wrote:

av wrote:

>On Wed, 13 Dec 2006 12:01:15 +0000, Mark McIntyre wrote:

>>>--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

this signature is OT, false and it irritate me: can you please change
it?

(a) It's a /signature/.

Well - while everything else you said is valid... signatures are four
lines, not six.

[Chris Dollin]

Random832 wrote:

2006-12-15 <el**********@m urdoch.hpl.hp.c om>,
Chris Dollin wrote:

>(a) It's a /signature/.

Well - while everything else you said is valid... signatures are four
lines, not six.

Signatures are /supposed/ to be no longer than 4 lines, but I don't
think being six lines long makes it a non-signature; it just makes
it an /excessively long/ signature. (Does the grammar of signatures
really exclude long signatures, or is in the nature of an implementation
restriction?)

--
Chris "Perikles triumphant" Dollin
"- born in the lab under strict supervision -", - Magenta, /Genetesis/

[Richard Heathfield]

Chris Dollin said:

Random832 wrote:

>2006-12-15 <el**********@m urdoch.hpl.hp.c om>,
Chris Dollin wrote:

>>(a) It's a /signature/.

Well - while everything else you said is valid... signatures are four
lines, not six.

Signatures are /supposed/ to be no longer than 4 lines, but I don't
think being six lines long makes it a non-signature; it just makes
it an /excessively long/ signature. (Does the grammar of signatures
really exclude long signatures, or is in the nature of an implementation
restriction?)

" - If you include a signature keep it short. Rule of thumb
is no longer than 4 lines. Remember that many people pay for
connectivity by the minute, and the longer your message is,
the more they pay."

---- RFC 1855

Whilst it is only a rule of thumb, it's a good one. And whilst this whole
RFC only has "informatio nal" status, it is nevertheless worth taking
seriously - about as seriously as you would take an ISO/IEC 9899 footnote,
I guess. That is to say, okay, it's not normative, but it's still a
guideline that the clueful will observe under most circumstances.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Mark McIntyre]

On Fri, 15 Dec 2006 09:44:30 +0100, in comp.lang.c , av <av@ala.a>
wrote:

>it not speak on "C language standard", it is about how difficult
should be to debug, an ot subject

maybe you didn't understand my sig in the post you are replying to. I
recommend you read it again. Meanwhile here's another that is quite
apposite...

--
"The lusers I know are so clueless, that if they were dipped in clue
musk and dropped in the middle of pack of horny clues, on clue prom
night during clue happy hour, they still couldn't get a clue."
--Michael Girdwood, in the monastery

[CBFalconer]

Chris Dollin wrote:

Random832 wrote:

>Chris Dollin wrote:

>>(a) It's a /signature/.

Well - while everything else you said is valid... signatures are
four lines, not six.

Signatures are /supposed/ to be no longer than 4 lines, but I
don't think being six lines long makes it a non-signature; it
just makes it an /excessively long/ signature. (Does the grammar
of signatures really exclude long signatures, or is in the nature
of an implementation restriction?)

Signatures are EVERYTHING that follows a "-- " sig marker. Some of
mine are considerably longer because they are pre-prepared help
messages, such as lists of references, or possibly designed to make
a political point.

s /supposed/recommended/

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

[Thad Smith]

Chris Torek wrote:

>>jacob navia wrote:

>>>A first tentative, definition for what a type is, could be 0x93a type is a
definition of an algorithm for understanding a sequence of storage
bits0x94.

In article <45************ ***********@aut h.newsreader.oc tanews.com>
Thad Smith <Th*******@acm. orgwrote:

>>I disagree that a type is a "definition of an algorithm". To me, it is
a specification of the meaning of the bits of a variable. I don't
associate such specifications directly with algorithms.

That might be a better "first, tentative definition" for a type,
as it is the actual definition of a concrete type. But given a
specification, one can derive an algorithm ... and it depends
on whether one wants to start with the concrete or the abstract.

I should have been clearer. An algorithm maps an input sequence to an output
sequence. You can consider the bits within a object of a particular type to be an
input sequence, but without a definition of an output sequence, you can't define
an algorithm. Not all data types encode a real (or complex) number. A complex
type might contain the state of an order in process. It can be used for multiple
purposes and has no inherent output.

A type, to me, defines the meaning of the bits. What process (algorithm) you
apply to that depends on your objective.

--
Thad