Classification of arithmetic types

[jacob navia]

As Richard Bos rightly pointed out, I had left in my classification
of types the C99 types Complex and boolean. Here is a new
classification. Those are not mentioned in the classification
of Plauger and Brody, probably because their work predates
C99. Since there are no examples of this in the literature
(known to me) please take a look.

Thanks
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 boolean type
3.1.1.1.1.2 char (signed/unsigned)
3.1.1.1.1.3 short (signed unsigned)
3.1.1.1.1.4 int (signed/unsigned)
3.1.1.1.1.5 long (signed/unsigned)
3.1.1.1.1.6 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 Real types
3.1.1.2.1.1 float
3.1.1.2.1.2 double
3.1.1.2.1.3 long double
3.1.1.2.4 Complex types
3.1.1.2.4.1 float Complex
3.1.1.2.4.2 double Complex
3.1.1.2.4.2 long double Complex

I would define arithmetic types as those that define the 4 operations.
This distiguishes them from pointer types where addition and
subtraction are defined but not multiplication/division.

Is that correct?

jacob

[CBFalconer]

Richard Bos wrote:

jacob navia <ja***@jacob.re mcomp.frwrote:

.... snip ...

>>
As far as I understood this stuff, all those are defined in terms
of one of the primitive types in the enumeration above.

Not necessarily. For example, on historic implementations , time_t
was often larger than a single long, and was therefore a struct.
Ditto for, e.g., fpos_t. The point about such types is that they
may be one specific primitive type on any particular implementation,
but to the wise C programmer they must remain abstract types. As
such, they deserve discussion.

As far as I am concerned, a 'type' means specifying the domain of
allowable values, together with a set of operations on those
values. C arithmetical types are extremely primitive, in that they
cannot precisely specify the domain. They tend to simply specify a
maximum (and minimum) value, which is pre-defined. This is one of
the primary causes of invalid indices.

Even an enum cannot specify the precise validity range in C. You
can catch unenumerated values with a switch statement having a
default case.

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

[CBFalconer]

Eric Sosman wrote:

>

.... snip ...

>
The Standard disagrees with you (6.2.5/14). `char' is a type unto
itself, distinct from both `signed char' and `unsigned char'.
`int' and `short' are distinct types even when both are 16 bits
wide; `int' and `long' are distinct even when both are 32 bits
wide; `double' and `long double' are distinct even when both are
IEEE double-precision numbers. Representation and behavior are
not the sole ingredients of "type."

Reminds me of the arguments about type compatibility during Pascal
standardization . It eventually became identical type names, rather
than composition.

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

[Eric Sosman]

CBFalconer wrote:

>
As far as I am concerned, a 'type' means specifying the domain of
allowable values, together with a set of operations on those
values. [...]

C's "type" is a little stronger/richer/fussier than that.
For example, `char' and `signed char' and `unsigned char' are
three distinct types, even though only two sets of values and
operations are evident. `double' and `long double' sometimes
share the same set of values and operations, yet the types
are distinct. The types

struct zaphod { int x; };
struct beeble { int x; };

offer the same set of values and support the same operations,
and yet are two distinct (and incompatible) types.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Keith Thompson]

Eric Sosman <es*****@acm-dot-org.invalidwrit es:
[...]

The types

struct zaphod { int x; };
struct beeble { int x; };

offer the same set of values and support the same operations,
and yet are two distinct (and incompatible) types.

<quibble>
They don't support the same operations, merely identical operations
(or perhaps isomorphic would be a better word). For example, struct
zaphod does not provide the operation of assigning to a struct beeble,
or vice versa.
</quibble>

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Bos]

jacob navia <ja***@jacob.re mcomp.frwrote:

Keith Thompson a écrit :

jacob navia <ja***@jacob.re mcomp.frwrites:

>I would define arithmetic types as those that define the 4 operations.
This distiguishes them from pointer types where addition and
subtraction are defined but not multiplication/division.

Is that correct?

You don't get to define "arithmetic types". The term is defined in
C99 6.2.5p18. (I believe your definition happens to match the
standard's definition.)

Read C99 6.2.5 before you speculate.

The standard just says:

"Integer and floating types are collectively called arithmetic types."

This definition is just an enumeration, not a functional
definition, that I would prefer.

What you prefer is really not important. _This_ is how the Standard
defines arithmetic types. If you want another definition, call it
something else. Don't behave as a wannabe Microsoft.

Richard

[jacob navia]

Richard Bos a écrit :

jacob navia <ja***@jacob.re mcomp.frwrote:

>>Keith Thompson a écrit :

>>>jacob navia <ja***@jacob.re mcomp.frwrites:
I would define arithmetic types as those that define the 4 operations.
This distiguishes them from pointer types where addition and
subtracti on are defined but not multiplication/division.

Is that correct?

You don't get to define "arithmetic types". The term is defined in
C99 6.2.5p18. (I believe your definition happens to match the
standard's definition.)

Read C99 6.2.5 before you speculate.

The standard just says:

"Integer and floating types are collectively called arithmetic types."

This definition is just an enumeration, not a functional
definition, that I would prefer.

What you prefer is really not important. _This_ is how the Standard
defines arithmetic types. If you want another definition, call it
something else. Don't behave as a wannabe Microsoft.

Richard

Look I am writing a tutorial, not a commentary to the Bible. The
definition of the standard just says:

The arithmetic types are these.

I want to define them in terms of manipulation, i.e. in terms
of their functionality: The arithmetic types have these operations in
common.

Besides it is not evident what Microsoft has to do here. I am in no
way implying that my humble tutorial is a standard for anything!

[Chris Dollin]

jacob navia wrote:

Look I am writing a tutorial, not a commentary to the Bible. The
definition of the standard just says:

The arithmetic types are these.

I want to define them in terms of manipulation, i.e. in terms
of their functionality: The arithmetic types have these operations in
common.

Do both. Say "The arithmetic types are <whatever>, and have these
operations in common:".

--
Chris "Perikles triumphant" Dollin
The "good old days" used to be much better.

[Richard Bos]

jacob navia <ja***@jacob.re mcomp.frwrote:

Richard Bos a écrit :

jacob navia <ja***@jacob.re mcomp.frwrote:

>Keith Thompson a écrit :

jacob navia <ja***@jacob.re mcomp.frwrites:

I would define arithmetic types as those that define the 4 operations.
This distiguishes them from pointer types where addition and
subtractio n are defined but not multiplication/division.

Is that correct?

You don't get to define "arithmetic types". The term is defined in
C99 6.2.5p18. (I believe your definition happens to match the
standard's definition.)

Read C99 6.2.5 before you speculate.

The standard just says:

"Integer and floating types are collectively called arithmetic types."

This definition is just an enumeration, not a functional
definition, that I would prefer.

What you prefer is really not important. _This_ is how the Standard
defines arithmetic types. If you want another definition, call it
something else. Don't behave as a wannabe Microsoft.

Look I am writing a tutorial, not a commentary to the Bible.

All the more reason to be precise, and not confuse the learners.

The definition of the standard just says:

The arithmetic types are these.

I want to define them in terms of manipulation,

You don't get to define what the Standard already has defined for you.
Again: if you want something defined by those operations, _call it
something else_. You can then point out that, _as far as you can grasp_,
that comes to the same thing as the Standard definition of arithmetic
types.

Richard