Velocity Reviews > Classification of arithmetic types

# Classification of arithmetic types

jacob navia
Guest
Posts: n/a

 12-11-2006
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

Eric Sosman
Guest
Posts: n/a

 12-11-2006
jacob navia wrote:
> 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)

Also "plain old char," a third type distinct from the other
two (even though it behaves identically to one of them).

> 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)

How about wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t,
and the <stdint.h> types?

> 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

float_t and double_t?

> 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

time_t, clock_t, wctrans_t, and wctype_t are difficult to
categorize.

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid

jacob navia
Guest
Posts: n/a

 12-11-2006
Eric Sosman a écrit :
> Also "plain old char," a third type distinct from the other
> two (even though it behaves identically to one of them).
> How about wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t,
> and the <stdint.h> types?
> time_t, clock_t, wctrans_t, and wctype_t are difficult to
> categorize.
>

As far as I understood this stuff, all those are defined in terms of
one of the primitive types in the enumeration above.
For instance, in many implementations size_t is unsigned long,
or time_t is long long, or clock_t is int, etc etc.

They are derived types defined in terms of a more primitive type.

The same applies to chart ("plain" char) since it is defined either
as unsigned or signed char, what means it is not another basic
type but a synonym for one of the char types.

jacob navia
Guest
Posts: n/a

 12-11-2006
jacob navia a écrit :
> The same applies to chart ("plain" char)
>

Not "chart" but "char" of course. Excuse me.

Richard Bos
Guest
Posts: n/a

 12-11-2006
jacob navia <(E-Mail Removed)> wrote:

> Eric Sosman a écrit :
> > Also "plain old char," a third type distinct from the other
> > two (even though it behaves identically to one of them).
> > How about wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t,
> > and the <stdint.h> types?
> > time_t, clock_t, wctrans_t, and wctype_t are difficult to
> > categorize.

>
> 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.

Richard

Eric Sosman
Guest
Posts: n/a

 12-11-2006
jacob navia wrote:
> Eric Sosman a écrit :
>> Also "plain old char," a third type distinct from the other
>> two (even though it behaves identically to one of them).
>> How about wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t,
>> and the <stdint.h> types?
>> time_t, clock_t, wctrans_t, and wctype_t are difficult to
>> categorize.
>>

>
> As far as I understood this stuff, all those are defined in terms of
> one of the primitive types in the enumeration above.
> For instance, in many implementations size_t is unsigned long,
> or time_t is long long, or clock_t is int, etc etc.

"In many implementations" doesn't quite make the grade for
a treatise that is supposed to be about the language and not
about particular implementations of it. "In many implementations"
it is true that INT_MIN < -INT_MAX, but that's not true of the
language per se.

Even in C90 I'm not entirely sure that all the "named for a
purpose" types were required to be aliases of "ordinary" types as
opposed to implementation-defined "exotic" types. Certainly in
C99 the lid came off, and int_least16_t (for example) might not
be a synonym for any kind of char, short, or int.

> The same applies to chart ("plain" char) since it is defined either
> as unsigned or signed char, what means it is not another basic
> type but a synonym for one of the char types.

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."

--
Eric Sosman
(E-Mail Removed)lid

P.J. Plauger
Guest
Posts: n/a

 12-11-2006
"Eric Sosman" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed). ..

> jacob navia wrote:
>> 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.

For an update of the Plauger & Brodie documentation, see the C
portion of our on-line manual:

http://www.dinkumware.com/manuals/

>> 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)

>
> Also "plain old char," a third type distinct from the other
> two (even though it behaves identically to one of them).
>
>> 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)

>
> How about wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t,
> and the <stdint.h> types?
>
>> 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

>
> float_t and double_t?
>
>> 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

>
> time_t, clock_t, wctrans_t, and wctype_t are difficult to
> categorize.

What the standard says about each of these types is summarized
in our manual.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

jacob navia
Guest
Posts: n/a

 12-11-2006
P.J. Plauger a écrit :
> "Eric Sosman" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed). ..
>
>
>>jacob navia wrote:
>>
>>>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.

>
>
> For an update of the Plauger & Brodie documentation, see the C
> portion of our on-line manual:
>
> http://www.dinkumware.com/manuals/
>
>
>>>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)

>>
>> Also "plain old char," a third type distinct from the other
>>two (even though it behaves identically to one of them).
>>
>>
>>> 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)

>>
>> How about wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t,
>>and the <stdint.h> types?
>>
>>
>>> 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

>>
>> float_t and double_t?
>>
>>
>>> 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

>>
>> time_t, clock_t, wctrans_t, and wctype_t are difficult to
>>categorize.

>
>
> What the standard says about each of these types is summarized
> in our manual.
>
> P.J. Plauger
> Dinkumware, Ltd.
> http://www.dinkumware.com
>
>

Thanks for your answer Mr Plauger but I could not find that type
classification there. Maybe you would give a more specific link?
I browsed a lot of C stuff (and C++ stuff) but could not find it.

Thanks

Keith Thompson
Guest
Posts: n/a

 12-11-2006
jacob navia <(E-Mail Removed)> writes:
> Eric Sosman a écrit :
>> Also "plain old char," a third type distinct from the other
>> two (even though it behaves identically to one of them).
>> How about wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t,
>> and the <stdint.h> types?
>> time_t, clock_t, wctrans_t, and wctype_t are difficult to
>> categorize.

>
> As far as I understood this stuff, all those are defined in terms of
> one of the primitive types in the enumeration above.
> For instance, in many implementations size_t is unsigned long,
> or time_t is long long, or clock_t is int, etc etc.

They're typedefs for some predefined integer type, possible an
extended integer type (which you didn't mention).

Incidentally, be careful with the word "enumeration" in this context.

> They are derived types defined in terms of a more primitive type.

No, the standard defines the term "derived type" (C99 6.2.5p20);
typedefs do not create derived types. If you're going to invent
terminology, be *very* careful to remain consistent with the standard.
Better yet, just use the standard's own terminology.

> The same applies to chart ("plain" char) since it is defined either
> as unsigned or signed char, what means it is not another basic
> type but a synonym for one of the char types.

No, type char is distinct from both signed char and unsigned char,
though it has the same characteristics as one of them. This usually
doesn't matter due to implicit conversions, but these types:

char*
unsigned char*
signed char*

are all incompatible; values of these types cannot be assigned to each
other without a cast. If char were an alias for either signed char or
unsigned char, this would not be the case. (Does lcc-win32 get this
right?)

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <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.

Keith Thompson
Guest
Posts: n/a

 12-11-2006
(E-Mail Removed) (Richard Bos) writes:
> jacob navia <(E-Mail Removed)> wrote:
>
>> Eric Sosman a écrit :
>> > Also "plain old char," a third type distinct from the other
>> > two (even though it behaves identically to one of them).
>> > How about wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t,
>> > and the <stdint.h> types?
>> > time_t, clock_t, wctrans_t, and wctype_t are difficult to
>> > categorize.

>>
>> 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.

Yes, but the standard specifically requires time_t to be an arithmetic
type (though there's not much you can do in portable code to take
advantage of this).

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <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.

 Thread Tools

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post mkr VHDL 5 11-24-2008 06:19 AM Frederick Gotham C++ 2 07-07-2006 06:48 PM Simon Morgan C Programming 8 08-18-2005 05:59 AM joshc C Programming 5 03-31-2005 02:23 AM Lionel B C++ 5 03-03-2005 12:30 PM

Advertisments