473,320 Members | 2,117 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Classification of arithmetic types

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
Dec 11 '06 #1
27 2001
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.htypes?
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
es*****@acm-dot-org.invalid
Dec 11 '06 #2
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.htypes?
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.
Dec 11 '06 #3
jacob navia a écrit :
The same applies to chart ("plain" char)
Not "chart" but "char" of course. Excuse me.

Dec 11 '06 #4
jacob navia <ja***@jacob.remcomp.frwrote:
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.htypes?
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
Dec 11 '06 #5
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.htypes?
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
es*****@acm-dot-org.invalid

Dec 11 '06 #6
"Eric Sosman" <es*****@acm-dot-org.invalidwrote in message
news:8o******************************@comcast.com. ..
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.htypes?
> 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
Dec 11 '06 #7
P.J. Plauger a écrit :
"Eric Sosman" <es*****@acm-dot-org.invalidwrote in message
news:8o******************************@comcast.com. ..

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

>> 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
Dec 11 '06 #8
jacob navia <ja***@jacob.remcomp.frwrites:
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.htypes?
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) 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.
Dec 11 '06 #9
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
jacob navia <ja***@jacob.remcomp.frwrote:
>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.htypes?
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) 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.
Dec 11 '06 #10
jacob navia <ja***@jacob.remcomp.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.

--
Keith Thompson (The_Other_Keith) 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.
Dec 11 '06 #11
Keith Thompson a écrit :
jacob navia <ja***@jacob.remcomp.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.

But this is not very important since the end result is the same.
Dec 11 '06 #12
Keith Thompson a écrit :
jacob navia <ja***@jacob.remcomp.frwrites:
>>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.
Mmmmm

" char is distinct from both signed char and unsigned char,
though it has the same characteristics as one of them" ...

I have some difficulty following you here. If it has the same
characteristics then is the same! How can a type
have the same characteristics (and name) and still be different?

long and int are different types since long can be longer than int,
even if in many implementations long == int. OK.

But char can never have a different size than one of the
signed/unsigned char types so IT IS the same...
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?)
Dunno. Char is signed by default.

Dec 11 '06 #13
jacob navia wrote:
Keith Thompson a écrit :
jacob navia <ja***@jacob.remcomp.frwrites:
>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.

Mmmmm

" char is distinct from both signed char and unsigned char,
though it has the same characteristics as one of them" ...

I have some difficulty following you here. If it has the same
characteristics then is the same! How can a type
have the same characteristics (and name) and still be different?
#include <limits.h>

#if CHAR_MIN < 0
typedef signed char plain_char;
#else
typedef unsigned char plain_char;
#endif

plain_char *a;
/* really plain */ char *b;

int main(void) {
a = b; /* disallowed */
b = a; /* disallowed */
}

If char were the same type as (un)signed char, this would be allowed.

Dec 11 '06 #14
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45**************@jacob.remcomp.fr...
Keith Thompson a écrit :
>jacob navia <ja***@jacob.remcomp.frwrites:
>>>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.

Mmmmm

" char is distinct from both signed char and unsigned char,
though it has the same characteristics as one of them" ...

I have some difficulty following you here. If it has the same
characteristics then is the same! How can a type
have the same characteristics (and name) and still be different?
The proper term, instead of "characteristics", is "representation".
It is often true in C that two types have the same representation
but are nevertheless considered by the compiler to be distinct
types. char/signed char or char/unsigned char is just one of these
pairs.
long and int are different types since long can be longer than int,
even if in many implementations long == int. OK.

But char can never have a different size than one of the
signed/unsigned char types so IT IS the same...
The same representation, yes.
>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?)

Dunno. Char is signed by default.
Sez who?

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Dec 11 '06 #15
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45***********************@news.orange.fr...
P.J. Plauger a écrit :
>"Eric Sosman" <es*****@acm-dot-org.invalidwrote in message
news:8o******************************@comcast.com ...

>>>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.htypes?
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.
We don't include the language portion of P&B in our latest manual,
since it's a pure library manual as much as possible. But you'll
find descriptions of the constraints on:

-- wchar_t, size_t, ptrdiff_t, sig_atomic_t, wint_t, and the
<stdint.htypes

-- time_t, clock_t, wctrans_t, and wctype_t

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Dec 11 '06 #16
On Mon, 11 Dec 2006 15:46:01 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>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 fact the standard _doesn't_ say they have to be synonyms to any
other type.

For instance clock_t and time_t merely have to be arithmetic, so it
could be a a 2560-bit double (7.23), irrespective of whether a long
double were 32, 64, 80 or 128 bits. Size_t has to be an unsigned
integer type - but again there's no restriction on width (7.17) so it
could be wider than long long. In fact such designs might actually
make sense - using an integer type for time _is_ kinda daft, while
size_t needs to be able to refer to all possible availalbe memory..
>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 C standard does explicitly say that its a distinct type
(6.2.5p15).
--
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
Dec 11 '06 #17
jacob navia <ja***@jacob.remcomp.frwrites:
Keith Thompson a écrit :
>jacob navia <ja***@jacob.remcomp.frwrites:
>>>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.

Mmmmm

" char is distinct from both signed char and unsigned char,
though it has the same characteristics as one of them" ...

I have some difficulty following you here. If it has the same
characteristics then is the same!
Um, no.
How can a type
have the same characteristics (and name) and still be different?
By having the same characteristics (*not* the same name) and still
being different. What's unclear about that?
long and int are different types since long can be longer than int,
even if in many implementations long == int. OK.
Right, assuming that "long == int" is a shorthand for "long and int
have the same range and size".

int* and float* may very well have exactly the same characteristics
(representation, alignment, etc.), but they're distinct types.

long and int are distinct types even if they happen to have the same
properties. It's exactly the same for char and signed char, and for
char and unsigned char.
But char can never have a different size than one of the
signed/unsigned char types so IT IS the same...
No, they're distinct types (that happen to have the same size). Are
you arguing that size is the only thing that determines whether two
types are the same? It isn't.

C99 6.2.5p15:

The three types char, signed char, and unsigned char are
collectively called the _character types_. The implementation
shall define char to have the same range, representation, and
behavior as either signed char or unsigned char.

with a footnote:

CHAR_MIN, defined in <limits.h>, will have one of the values 0 or
SCHAR_MIN, and this can be used to distinguish the two
options. Irrespective of the choice made, char is a separate type
from the other two and is not compatible with either.
>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?)

Dunno. Char is signed by default.
Try compiling this:

#include <limits.h>
int main(void)
{
char *cp;
unsigned char *up;
signed char *sp;

#if CHAR_MIN == 0
/* plain char is unsigned */
cp = up; /* constraint violation */
#else
/* plain char is signed */
cp = sp; /* constraint violation */
#endif
return 0;
}

A conforming compiler must issue a diagnostic for whichever assignment
is not deleted by the preprocessor. (If the diagnostic includes a
line number, it will tell you whether plain char is signed or
unsigned.) What does lcc-win32 do (in conforming mode)?

--
Keith Thompson (The_Other_Keith) 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.
Dec 11 '06 #18
"P.J. Plauger" <pj*@dinkumware.comwrites:
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45**************@jacob.remcomp.fr...
>Keith Thompson a écrit :
[...]
>>If char were an alias for either signed char or unsigned char,
this would not be the case. (Does lcc-win32 get this right?)

Dunno. Char is signed by default.

Sez who?
Sez lcc-win32, presumably, since I had just asked him a question about
it.

--
Keith Thompson (The_Other_Keith) 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.
Dec 11 '06 #19
Richard Bos wrote:
jacob navia <ja***@jacob.remcomp.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>
Dec 11 '06 #20
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>
Dec 11 '06 #21
"P.J. Plauger" <pj*@dinkumware.comwrites:
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45**************@jacob.remcomp.fr...
>Keith Thompson a écrit :
>>jacob navia <ja***@jacob.remcomp.frwrites:

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.

Mmmmm

" char is distinct from both signed char and unsigned char,
though it has the same characteristics as one of them" ...

I have some difficulty following you here. If it has the same
characteristics then is the same! How can a type
have the same characteristics (and name) and still be different?

The proper term, instead of "characteristics", is "representation".
It is often true in C that two types have the same representation
but are nevertheless considered by the compiler to be distinct
types. char/signed char or char/unsigned char is just one of these
pairs.
[...]

I used the more general term "characteristics" because there's more to
it than just the representation. Plain char and (signed|unsigned)
char have the same representation, alignment, minimum and maximum
valiues, and probably some other things I haven't thought of. Or are
all those things considered part of the "representation"?

Plain char and (signed|unsigned) char are identical in all respects
*except* that they have different names and are distinct types.

--
Keith Thompson (The_Other_Keith) 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.
Dec 11 '06 #22
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
Dec 11 '06 #23
Eric Sosman <es*****@acm-dot-org.invalidwrites:
[...]
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_Keith) 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.
Dec 11 '06 #24
jacob navia <ja***@jacob.remcomp.frwrote:
Keith Thompson a écrit :
jacob navia <ja***@jacob.remcomp.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
Dec 12 '06 #25
Richard Bos a écrit :
jacob navia <ja***@jacob.remcomp.frwrote:

>>Keith Thompson a écrit :
>>>jacob navia <ja***@jacob.remcomp.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
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!
Dec 12 '06 #26
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.

Dec 12 '06 #27
jacob navia <ja***@jacob.remcomp.frwrote:
Richard Bos a écrit :
jacob navia <ja***@jacob.remcomp.frwrote:
>Keith Thompson a écrit :

jacob navia <ja***@jacob.remcomp.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.

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
Dec 14 '06 #28

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: Lionel B | last post by:
Greetings, I am trying to implement "element-wise" arithmetic operators for a class along the following lines (this is a simplified example): // ----- BEGIN CODE ----- struct X { int a,b;
16
by: TTroy | last post by:
Hello, I'm relatively new to C and have gone through more than 4 books on it. None mentioned anything about integral promotion, arithmetic conversion, value preserving and unsigned preserving. ...
4
by: PDHB | last post by:
I'm sorry, but this is just the height of stupidity. I love the dot net framework. It has actually been sufficient to convert an anti-microsoft extremist (myself) to the windows camp. But not...
2
by: Frederick Gotham | last post by:
I just want to clarify my understanding of arithmetic and comparison between two different integer types. Phase (1): Integer Promotion ---------- All of the following types always get...
26
by: Bill Reid | last post by:
Bear with me, as I am not a "professional" programmer, but I was working on part of program that reads parts of four text files into a buffer which I re-allocate the size as I read each file. I...
6
by: sarathy | last post by:
Hi, What is integer promotion? How is it different from arithmetic conversion? Regards, Sarathy
6
by: Grant Robertson | last post by:
I am interested in including classification info in metadata. I am aware of the Dublin Core and XMP. However, neither of these appear to specify exactly how the classification data should be...
4
by: Evan Klitzke | last post by:
Hi all, What frameworks are there available for doing pattern classification? I'm generally interested in the problem of mapping some sort of input to one or more categories. For example, I want...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.