Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #4520 > unrolled thread
| Started by | jacob navia <jacob@spamsink.net> |
|---|---|
| First post | 2011-05-22 21:29 +0200 |
| Last post | 2011-06-02 15:26 -0700 |
| Articles | 20 on this page of 123 — 20 participants |
Back to article view | Back to comp.lang.c
Types in C jacob navia <jacob@spamsink.net> - 2011-05-22 21:29 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-22 12:48 -0700
Re: Types in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-22 23:03 +0100
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 10:35 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 08:40 -0700
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 17:19 +0000
Re: Types in C John Gordon <gordon@panix.com> - 2011-05-23 17:54 +0000
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 11:33 -0700
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 11:44 -0700
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 19:08 +0000
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 20:50 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 12:11 -0700
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 19:45 +0000
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 13:03 -0700
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 22:25 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 14:38 -0700
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 23:45 +0200
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 22:02 +0000
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-24 00:10 +0200
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 22:12 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 13:27 -0700
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 22:33 +0200
Re: Types in C Martin Ambuhl <mambuhl@earthlink.net> - 2011-05-24 03:17 -0400
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-24 10:55 +0200
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 09:29 +1200
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 23:42 +0200
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 09:51 +1200
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-24 00:04 +0200
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 10:57 +1200
Re: Types in C David Thompson <dave.thompson2@verizon.net> - 2011-06-01 16:33 -0400
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-23 19:33 -0500
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 08:27 -0700
Re: Types in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-31 00:40 -0700
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-31 11:32 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-31 11:30 -0700
Re: Types in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-01 01:23 -0700
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 16:51 -0400
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 09:25 +1200
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 23:40 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 08:36 -0700
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 17:53 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 22:24 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 19:23 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 23:57 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 21:22 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 03:46 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 00:24 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 04:44 +0000
Re: Types in C pete <pfiland@mindspring.com> - 2011-05-24 07:46 -0400
Re: Types in C James Kuyper <jameskuyper@verizon.net> - 2011-05-24 07:48 -0400
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 10:35 +1200
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 22:38 +0000
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 10:53 +1200
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 23:17 +0000
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 11:24 +1200
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 23:39 +0000
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-24 11:23 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 08:46 -0700
Re: Types in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-24 09:14 -0700
Re: Types in C Michael Press <rubrum@pacbell.net> - 2011-05-28 21:50 -0700
Re: Types in C "io_x" <a@b.c.invalid> - 2011-06-07 19:50 +0200
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 19:33 -0400
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 12:03 +1200
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 21:27 -0400
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 13:47 +1200
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 23:45 -0400
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 00:07 -0700
Re: Types in C James Kuyper <jameskuyper@verizon.net> - 2011-05-24 08:05 -0400
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-23 19:54 -0500
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 21:03 -0400
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-23 22:12 -0500
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 00:03 -0400
Re: Types in C pete <pfiland@mindspring.com> - 2011-05-24 00:19 -0400
Re: Types in C pete <pfiland@mindspring.com> - 2011-05-24 00:20 -0400
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-24 00:46 -0500
Re: Types in C pete <pfiland@mindspring.com> - 2011-05-24 07:36 -0400
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 10:58 -0400
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 09:40 -0700
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 21:36 -0400
Re: Types in C David Thompson <dave.thompson2@verizon.net> - 2011-06-01 16:33 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 16:50 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 21:10 -0400
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 18:19 -0700
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 21:42 -0400
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-24 23:47 -0500
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-25 10:13 -0400
Re: Types in C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-24 22:19 -0600
Re: Types in C Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-25 07:04 +0100
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-25 08:53 -0700
Re: Types in C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-25 10:11 -0600
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 09:02 -0700
Re: Types in C James Kuyper <jameskuyper@verizon.net> - 2011-05-24 07:37 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 22:02 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 18:15 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 22:25 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 19:39 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 23:57 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 21:10 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 01:58 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 23:56 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 04:32 +0000
Re: Types in C "BartC" <bc@freeuk.com> - 2011-05-25 01:29 +0100
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-23 22:20 -0500
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-23 22:42 -0500
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 00:07 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 04:44 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 10:24 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 16:50 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 21:16 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-25 03:36 +0000
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-24 01:26 -0500
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 11:04 -0400
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 09:06 -0700
Re: Types in C David Thompson <dave.thompson2@verizon.net> - 2011-06-01 16:33 -0400
Re: Types in C Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-05-30 22:42 +0200
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-30 17:45 -0500
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-31 08:47 -0700
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-31 13:54 -0400
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-31 00:16 +0200
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-30 18:30 -0500
Re: Types in C Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-06-02 22:44 +0200
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-06-02 22:49 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-06-02 15:26 -0700
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-05-22 21:29 +0200 |
| Subject | Types in C |
| Message-ID | <irbo6c$ul$1@speranza.aioe.org> |
Hi I am updating my tutorial of C, and I have added a section of type classification. Please tell me if I forgot something or said something wrong if possible. Thanks in advance for your help A C type can be either a function type, an incomplete type or an object type. Function types can be either fully specified, i.e. we have a prototype available, or partially specified with missing arguments but a known return value. The function type "implicit int function" with return value and arguments unknown, has been declared obsolete in C99. Incomplete types are unspecified and it is assumed that they will be specified elsewhere, except for the void type that is an incomplete type that can't be further specified. Object types can be either scalar or composite types. Composite types are built from the scalar types: structures, unions and arrays. Scalar types are of two kinds: arithmetic or pointer types. Pointer types can point to scalar or composite types, to functions or to incomplete types. Arithmetic types have two kinds: integer types and floating types. The integer types are either standard integers, bit fields or enumerations. The standard integer types are boolean, char, short, int, long and long long, all with signed or unsigned types, except the boolean type that hasn't any sign but is not an unsigned type. Floating types are either real or complex, with both of them appearing in three flavors: float, double and long double.
[toc] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-22 12:48 -0700 |
| Message-ID | <ln8vtyzfcd.fsf@nuthaus.mib.org> |
| In reply to | #4520 |
jacob navia <jacob@spamsink.net> writes:
> I am updating my tutorial of C, and I have added a section of type
> classification. Please tell me if I forgot something or said
> something wrong if possible.
>
> Thanks in advance for your help
>
>
> A C type can be either a function type, an incomplete type or an object
> type. Function types can be either fully specified, i.e. we have a
> prototype available, or partially specified with missing arguments but
> a known return value. The function type "implicit int function" with
> return value and arguments unknown, has been declared obsolete in C99.
In C90, "implicit int function" isn't a distinct type.
foo(void);
and
int foo(void);
are merely two different ways of expressing exactly the same thing.
The return type isn't unknown, it's int.
> Incomplete types are unspecified and it is assumed that they will be
> specified elsewhere, except for the void type that is an incomplete
> type that can't be further specified.
>
> Object types can be either scalar or composite types. Composite types
> are built from the scalar types: structures, unions and arrays. Scalar
> types are of two kinds: arithmetic or pointer types. Pointer types can
> point to scalar or composite types, to functions or to incomplete types.
The phrase "composite type" has a very different meaning; see C99 6.2.7.
The standard refers to array and structure types (but not union types)
as "aggregate types". It doesn't seem to have a term that covers
arrays, structures and unions (and I'd be very hesitant in this kind of
tutorial to invent terms that aren't in the standard).
> Arithmetic types have two kinds: integer types and floating types. The
> integer types are either standard integers, bit fields or enumerations.
>
> The standard integer types are boolean, char, short, int, long and long
> long, all with signed or unsigned types, except the boolean type
> that hasn't any sign but is not an unsigned type.
You didn't mention extended integer types. I don't know whether you
want to.
> Floating types are either real or complex, with both of them appearing
> in three flavors: float, double and long double.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-05-22 23:03 +0100 |
| Message-ID | <0.19dd82b3beedde195878.20110522230329BST.87mxieo0jy.fsf@bsb.me.uk> |
| In reply to | #4520 |
jacob navia <jacob@spamsink.net> writes: > I am updating my tutorial of C, and I have added a section of type > classification. Please tell me if I forgot something or said > something wrong if possible. I'd add few remarks to what Keith Thompson has said. > A C type can be either a function type, an incomplete type or an object > type. Function types can be either fully specified, i.e. we have a > prototype available, or partially specified with missing arguments but > a known return value. The function type "implicit int function" with > return value and arguments unknown, has been declared obsolete in C99. > > Incomplete types are unspecified and it is assumed that they will be > specified elsewhere, except for the void type that is an incomplete > type that can't be further specified. Form a style point of view, this listing of terms followed by definitions (your paragraphs below all start with some category of type) is not that helpful. Often the definition of a term is the least interesting thing about it. That's particularly true of incomplete types. I'd explain them by stating how they often occur: "It is sometimes helpful to postpone or omit the full specification of a type. Such a partial definition of an object type gives rise an incomplete type. The type definition will usually be completed later in the source file or in another source file where the full details are finally needed. Until a type is complete, the size of the type is unknown and objects of the type can't be defined. The type void is rather special. It is an incomplete type that can never be completed." > Object types can be either scalar or composite types. Composite types > are built from the scalar types: structures, unions and arrays. Scalar > types are of two kinds: arithmetic or pointer types. Pointer types can > point to scalar or composite types, to functions or to incomplete types. > > Arithmetic types have two kinds: integer types and floating types. The > integer types are either standard integers, bit fields or > enumerations. I don't think bit fields are really types. They have a type, but you can't declare something to have a bit-field type. I'd leave them out altogether -- I think they are better explained as a special kind of structure members. > The standard integer types are boolean, char, short, int, long and long > long, all with signed or unsigned types, except the boolean type > that hasn't any sign but is not an unsigned type. boolean is not a type in C. You could say "bool (the Boolean type)" or you could use the real type name _Bool, ugly though it is. Also, _Bool *is* an unsigned type. Technically, char is not listed as one of the "standard integer types". "signed char" is one and so is the unsigned type that corresponds to it, but char is a third type different to these two. It is included in the group called "integer types". The problem is that the term "standard integer type" is used to distinguish these types form "extended integer types". If you dropped the word "standard" from that paragraph, there would be not possibility of confusion. > Floating types are either real or complex, with both of them appearing > in three flavors: float, double and long double. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-05-23 10:35 +0200 |
| Message-ID | <ird68c$59n$1@speranza.aioe.org> |
| In reply to | #4530 |
Le 23/05/11 00:03, Ben Bacarisse a écrit : > Form a style point of view, this listing of terms followed by > definitions (your paragraphs below all start with some category of type) > is not that helpful. Often the definition of a term is the least > interesting thing about it. That's particularly true of incomplete > types. I'd explain them by stating how they often occur: > Of course I go later into each type with a lot of detail. This is just the introduction to types, the "big picgture". There is actually a picture that shows all the relationships as I described. > > I don't think bit fields are really types. They have a type, but you > can't declare something to have a bit-field type. I'd leave them out > altogether -- I think they are better explained as a special kind of > structure members. > I have them in because they were in the classification that I used as base by Plauger and Brody. >> The standard integer types are boolean, char, short, int, long and long >> long, all with signed or unsigned types, except the boolean type >> that hasn't any sign but is not an unsigned type. > > boolean is not a type in C. You could say "bool (the Boolean type)" or > you could use the real type name _Bool, ugly though it is. Also, _Bool > *is* an unsigned type. > Yes, I corrected both counts. bool was added to the unsigned types. > Technically, char is not listed as one of the "standard integer types". > "signed char" is one and so is the unsigned type that corresponds to it, > but char is a third type different to these two. It is included in the > group called "integer types". The problem is that the term "standard > integer type" is used to distinguish these types form "extended integer > types". If you dropped the word "standard" from that paragraph, there > would be not possibility of confusion. > I added: <quote> The char type has not only signed and unsigned flavors but in some more esoteric classifications has a third flavor "plain char", different as a type from an unsigned or a signed char. We will not go into that hair splitting here. <end quote> I think this gives the reader a glimpse into the underlying complexities without really getting bogged down... True "hair splitting" is maybe exaggerated but it conveys my feeling about that whole issue :-) Thanks for your help
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-23 08:40 -0700 |
| Message-ID | <lnvcx1xw6m.fsf@nuthaus.mib.org> |
| In reply to | #4557 |
jacob navia <jacob@spamsink.net> writes:
[...]
> I added:
>
> <quote>
> The char type has not only signed and unsigned flavors but in some more
> esoteric classifications has a third flavor "plain char", different as a
> type from an unsigned or a signed char. We will not go into that
> hair splitting here.
> <end quote>
>
> I think this gives the reader a glimpse into the underlying complexities
> without really getting bogged down...
>
> True "hair splitting" is maybe exaggerated but it conveys my feeling
> about that whole issue :-)
Plain char really is a disinct time from both signed char and
unsigned char, just as int and long are distinct types even if they
happen to have exactly the same representation. IMHO you're not
serving your readers well by suggesting that this distinction is
"esoteric" and "hair splitting".
The phrase "in some more esoteric classifications" could lead some
readers to think that they should be using signed char or unsigned
char, and that plain char should be avoided. If I didn't know C,
I might even assume that most compilers don't support plain char.
Yes, it does seem odd that plain char has exactly the same
representation as either signed char or unsigned char, but that
it's a distinct type. But the alternative would be that plain char
is the same type as either signed char or unsigned char -- which
would make some programs either valid or uncompilable, depending
on the implementation. Would you rather be writing a tutorial for
that hypothetical language?
And I think the reason it seems strange is the misperception that
type is *just* about representation. It isn't. C is less strongly
typed than some languages, but it still has the concept tha two types
can be distinct even if one happens to be an exact copy of the other.
That might be something to explore in another part of your tutorial
(probably not the introduction).
Teach the language as it is, not as you wish it were.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-05-23 17:19 +0000 |
| Message-ID | <slrnitl4c6.o5q.usenet-nospam@guild.seebs.net> |
| In reply to | #4564 |
On 2011-05-23, Keith Thompson <kst-u@mib.org> wrote: > The phrase "in some more esoteric classifications" could lead some > readers to think that they should be using signed char or unsigned > char, and that plain char should be avoided. If I didn't know C, > I might even assume that most compilers don't support plain char. Hmm. This whole thread reminds me: I wrote an article series on the C type system long ago for IBM developerWorks, and I bet it's got errors that some of the clever folks here could catch. http://www.ibm.com/developerworks/power/library/pa-ctypes1/index.html http://www.ibm.com/developerworks/power/library/pa-ctypes2/index.html http://www.ibm.com/developerworks/power/library/pa-ctypes3/index.html http://www.ibm.com/developerworks/power/library/pa-ctypes4/index.html -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | John Gordon <gordon@panix.com> |
|---|---|
| Date | 2011-05-23 17:54 +0000 |
| Message-ID | <ire70p$iaf$1@reader1.panix.com> |
| In reply to | #4569 |
In <slrnitl4c6.o5q.usenet-nospam@guild.seebs.net> Seebs <usenet-nospam@seebs.net> writes:
> This whole thread reminds me: I wrote an article series on the C type
> system long ago for IBM developerWorks, and I bet it's got errors that
> some of the clever folks here could catch.
Not really an error, but is notation such as /byte/ meant to be italic
text?
--
John Gordon A is for Amy, who fell down the stairs
gordon@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-23 11:33 -0700 |
| Message-ID | <lnk4dhxo69.fsf@nuthaus.mib.org> |
| In reply to | #4570 |
John Gordon <gordon@panix.com> writes:
> In <slrnitl4c6.o5q.usenet-nospam@guild.seebs.net> Seebs <usenet-nospam@seebs.net> writes:
>> This whole thread reminds me: I wrote an article series on the C type
>> system long ago for IBM developerWorks, and I bet it's got errors that
>> some of the clever folks here could catch.
>
> Not really an error, but is notation such as /byte/ meant to be italic
> text?
Without having looked at the web pages (yet), I would assume so, because
"byte" is defined by the C standard.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-23 11:44 -0700 |
| Message-ID | <lnd3j9xnms.fsf@nuthaus.mib.org> |
| In reply to | #4572 |
Keith Thompson <kst-u@mib.org> writes:
> John Gordon <gordon@panix.com> writes:
>> In <slrnitl4c6.o5q.usenet-nospam@guild.seebs.net> Seebs <usenet-nospam@seebs.net> writes:
>>> This whole thread reminds me: I wrote an article series on the C type
>>> system long ago for IBM developerWorks, and I bet it's got errors that
>>> some of the clever folks here could catch.
>>
>> Not really an error, but is notation such as /byte/ meant to be italic
>> text?
>
> Without having looked at the web pages (yet), I would assume so, because
> "byte" is defined by the C standard.
And now I see that I completely misunderstood your question.
The word "byte" appears on the web page surrounded by '/' characters;
yes, it should be in italics without the '/' characters.
When my newsreader saw "/byte/" in John's article, it helpfully tried to
display it in italics (which my terminal emulator doesn't support) and
dropped the '/' characters. I'll need to figure out how to tell it not
to do that. (Something to do with gnus-emphasis-alist, I think.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-05-23 19:08 +0000 |
| Message-ID | <slrnitl83v.qf2.usenet-nospam@guild.seebs.net> |
| In reply to | #4570 |
On 2011-05-23, John Gordon <gordon@panix.com> wrote: > In <slrnitl4c6.o5q.usenet-nospam@guild.seebs.net> Seebs <usenet-nospam@seebs.net> writes: >> This whole thread reminds me: I wrote an article series on the C type >> system long ago for IBM developerWorks, and I bet it's got errors that >> some of the clever folks here could catch. > Not really an error, but is notation such as /byte/ meant to be italic > text? Probably. I thought the editor had caught all of those! -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-05-23 20:50 +0200 |
| Message-ID | <ireaa0$92r$1@speranza.aioe.org> |
| In reply to | #4569 |
Le 23/05/11 19:19, Seebs a écrit :
> On 2011-05-23, Keith Thompson<kst-u@mib.org> wrote:
>> The phrase "in some more esoteric classifications" could lead some
>> readers to think that they should be using signed char or unsigned
>> char, and that plain char should be avoided. If I didn't know C,
>> I might even assume that most compilers don't support plain char.
>
> Hmm.
>
> This whole thread reminds me: I wrote an article series on the C type
> system long ago for IBM developerWorks, and I bet it's got errors that
> some of the clever folks here could catch.
>
> http://www.ibm.com/developerworks/power/library/pa-ctypes1/index.html
> http://www.ibm.com/developerworks/power/library/pa-ctypes2/index.html
> http://www.ibm.com/developerworks/power/library/pa-ctypes3/index.html
> http://www.ibm.com/developerworks/power/library/pa-ctypes4/index.html
>
> -s
Interesting. What this discussion is concerned, you define
<quote>
The type of an object in C describes the way in which a chunk of memory
is associated with a value. In many cases, a type describes a computer's
native ways of representing values. For instance, on a typical UNIX®
system, declaring a variable as int will reserve enough storage to hold
a single processor register. This variable will be manipulated by
processor-native instructions, and will have the semantics native to the
processor.
<end quote>
I used a more functional definition of type. The equivalent sentence in
my book is:
<quote>
\subsection{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 as specified by its bits.
If we say that the type of a is a double, it means that the bits are to
be understood as the IEEE 754 (for instance) standard sequences of bits
representing a double precision floating point value.
A second, more refined definition would encompass the first but add the
notion of "concept" behind a type. For instance in some machines
the type "size_t" has exactly the same bits as an unsigned long, yet,
it is a different type. The difference is that we store sizes in
size_t objects, and not some arbitrary integer. The type is associated
with the concept of size. We use types to convey a concept to the
reader of the program.
The base of C's type hierarchy are the machine types, i.e. the types
that the integrated circuit understands. C has abstracted from the
myriad of machine types some types like 'int' or 'double' that are
almost universally present in all processors.
There are many machine types that C doesn't natively support, for
instance some processors support BCD coded data but that data is
accessible only through special libraries in C.
C makes an abstraction of the many machine types present in many
processors, selecting only some of them and ignoring others.
It can be argued why a type makes its way into the language and why
another doesn't. For instance the most universal type always present in
all binary machines is the boolean type (one or zero). Still, it was
ignored by the language until the C99 standard incorporated it as a
native type.
<end quote>
I think that both paragraphs convey more or less the same thing,
even if I would say you could have expanded a bit the definition part.
Afterwards, most of what you say is similar to what I have written,
but obviously in 4 articles you have much less space than me in a
book with not any hard page limit.
jacob
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-23 12:11 -0700 |
| Message-ID | <lnaaed2pwu.fsf@nuthaus.mib.org> |
| In reply to | #4574 |
jacob navia <jacob@spamsink.net> writes:
[...]
> A second, more refined definition would encompass the first but add the
> notion of "concept" behind a type. For instance in some machines
> the type "size_t" has exactly the same bits as an unsigned long, yet,
> it is a different type. The difference is that we store sizes in
> size_t objects, and not some arbitrary integer. The type is associated
> with the concept of size. We use types to convey a concept to the
> reader of the program.
[...]
Just a quibble: size_t may be exactly the same type as unsigned long,
since a typedef merely creates an alias for an existing type, not
a new and distinct type. plain char and signed char (for example)
are distinct in a way that size_t and unsigned long (for example)
are not.
On the system I'm currently using, size_t happens to be a typedef for
unsigned int. Given the following program:
#include <stddef.h>
int main(void)
{
size_t *size_t_ptr = NULL;
unsigned int *unsigned_int_ptr = NULL;
unsigned long *unsigned_long_ptr = NULL;
signed char *signed_char_ptr = NULL;
unsigned char *unsigned_char_ptr = NULL;
char *plain_char_ptr = NULL;
size_t_ptr = unsigned_int_ptr; /* line 12 */
size_t_ptr = unsigned_long_ptr; /* line 13 */
plain_char_ptr = signed_char_ptr; /* line 15 */
plain_char_ptr = unsigned_char_ptr; /* line 16 */
return 0;
}
gcc (with the proper options) warns about lines 13, 15, and 16.
Any conforming compiler must diagnose lines 15 and 16, and will
probably diagnose exactly one of lines 12 and 13 (it could diagnose
both if, for example, size_t is unsigned long long).
Of course size_t should be thought of as something that's quite
distinct from any predefined integer type, but the thing that's
distinct is something other than a C type. (IMHO this is a weakness
of C's type system.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-05-23 19:45 +0000 |
| Message-ID | <slrnitldk4.tio.usenet-nospam@guild.seebs.net> |
| In reply to | #4578 |
On 2011-05-23, Keith Thompson <kst-u@mib.org> wrote: > Just a quibble: size_t may be exactly the same type as unsigned long, > since a typedef merely creates an alias for an existing type, not > a new and distinct type. plain char and signed char (for example) > are distinct in a way that size_t and unsigned long (for example) > are not. True. Although, possibly confusingly, there are places where it seems that the thing a typedef creates is itself then called "a type". The wording is a bit fuzzy. We all know what we mean, I think. You could say it several ways: Typedef does not actually create types; instead, it creates names which refer to existing types. Typedef creates types, but those types are identical to existing types and can be used interchangably with them. These appear to me to be essentially equivalent. I tend to think of the created name as being "a type" because my map has "type" connecting to "the mapping from a name to a representation and storage thing", but of course this isn't quite right, because of the plain char and (either signed or unsigned char) equivalence; it's the same representation and such as one of them, but it's not the same type as either. I'm aware this isn't quite how it works, but consider this point you made: > Of course size_t should be thought of as something that's quite > distinct from any predefined integer type, but the thing that's > distinct is something other than a C type. (IMHO this is a weakness > of C's type system.) Yes. I would love to know how much code would ACTUALLY break if typedef created "types". Such that, say: typedef int a; typedef int b; a foo; b *bar = &foo; was a constraint violation. My guess is it would work well. And that's why I tend to treat C *as if* that were true, because the only code which I regard as "broken" which isn't broken according to the C type system is generally bad code, and it prevents me from doing stupid things as much. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-23 13:03 -0700 |
| Message-ID | <ln1uzp2nh5.fsf@nuthaus.mib.org> |
| In reply to | #4582 |
Seebs <usenet-nospam@seebs.net> writes:
> On 2011-05-23, Keith Thompson <kst-u@mib.org> wrote:
>> Just a quibble: size_t may be exactly the same type as unsigned long,
>> since a typedef merely creates an alias for an existing type, not
>> a new and distinct type. plain char and signed char (for example)
>> are distinct in a way that size_t and unsigned long (for example)
>> are not.
>
> True. Although, possibly confusingly, there are places where it seems
> that the thing a typedef creates is itself then called "a type". The
> wording is a bit fuzzy.
(Didn't we already have this discussion?)
> We all know what we mean, I think. You could say it several ways:
>
> Typedef does not actually create types; instead, it creates
> names which refer to existing types.
That's my preference.
> Typedef creates types, but those types are identical to existing
> types and can be used interchangably with them.
I dislike that description.
Given:
typedef unsigned int word;
there is only one *type* being considered; it has two *names*, "unsigned
int" and "word". "unsigned int" is not itself a type; it's a sequence
of keywords that is the *name* of a type.
And using the idea of "identical types" makes it difficult to discuss
the difference between the relationship of size_t vs. unsigned int
(same type) and the relationship of char vs. signed char (identical
but distinct types).
> These appear to me to be essentially equivalent. I tend to think of
> the created name as being "a type" because my map has "type" connecting
> to "the mapping from a name to a representation and storage thing", but
> of course this isn't quite right, because of the plain char and (either
> signed or unsigned char) equivalence; it's the same representation and
> such as one of them, but it's not the same type as either.
>
> I'm aware this isn't quite how it works, but consider this point you
> made:
>
>> Of course size_t should be thought of as something that's quite
>> distinct from any predefined integer type, but the thing that's
>> distinct is something other than a C type. (IMHO this is a weakness
>> of C's type system.)
>
> Yes.
And the "thing that's distinct", I now realize, is simply the *name*.
> I would love to know how much code would ACTUALLY break if typedef
> created "types". Such that, say:
> typedef int a;
> typedef int b;
> a foo;
> b *bar = &foo;
> was a constraint violation.
>
> My guess is it would work well.
My guess is that it would break a lot of code. It would be a good
thing, IMHO, if size_t were distinct from any predefined type (which
would break only code that deserves to be broken).
> And that's why I tend to treat C *as if* that were true, because the only
> code which I regard as "broken" which isn't broken according to the C type
> system is generally bad code, and it prevents me from doing stupid things
> as much.
Typedefs are used in different ways. Sometimes a typedef creates a name
for a type, when the type being named may vary from one system to
another, or from one version of the program to another (size_t, word).
And sometimes a typedef just creates a name for a type because you don't
like the existing name, but the type being named will never change.
Some examples of the latter:
typedef unsigned long ulong; /* I don't do this myself */
typedef unsigned char byte;
typedef struct node {
struct node *next;
int data;
} node;
Note that if "struct node" and "node" were two distinct types, this
wouldn't work.
I would have liked to see one mechanism that creates a new name for a
type, and another that creates a new distinct type with the same
characteristics as an existing type. (Ada has this, "subtype"
vs. "derived type".)
On the other hand, C does have a mechanism for creating new types, the
"struct" keyword.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-05-23 22:25 +0200 |
| Message-ID | <irefqs$o65$1@speranza.aioe.org> |
| In reply to | #4583 |
Le 23/05/11 22:03, Keith Thompson a écrit : > Seebs<usenet-nospam@seebs.net> writes: >> >> Typedef does not actually create types; instead, it creates >> names which refer to existing types. > > That's my preference. You just do not understand Thompson. size_t will be identical to unsigned int in your machine but in my Mac OSX it is identical to unsigned long long. But it is the same type: size_t. size_t is an *abstraction* of the underlying type, it is NOT the underlying type even if you say that size_t is unsigned int in YOUR machine. The goal of size_t is to HIDE the underlying type not just to name an underlying type with another name.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-23 14:38 -0700 |
| Message-ID | <lnlixx14iz.fsf@nuthaus.mib.org> |
| In reply to | #4588 |
jacob navia <jacob@spamsink.net> writes:
> Le 23/05/11 22:03, Keith Thompson a écrit :
>> Seebs<usenet-nospam@seebs.net> writes:
>>>
>>> Typedef does not actually create types; instead, it creates
>>> names which refer to existing types.
>>
>> That's my preference.
>
> You just do not understand Thompson.
C99 6.7.7p3 says:
A typedef declaration does not introduce a new type, only a
synonym for the type so specified.
Is the standard wrong?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-05-23 23:45 +0200 |
| Message-ID | <irekha$4dt$3@speranza.aioe.org> |
| In reply to | #4601 |
Le 23/05/11 23:38, Keith Thompson a écrit : > jacob navia<jacob@spamsink.net> writes: >> Le 23/05/11 22:03, Keith Thompson a écrit : >>> Seebs<usenet-nospam@seebs.net> writes: >>>> >>>> Typedef does not actually create types; instead, it creates >>>> names which refer to existing types. >>> >>> That's my preference. >> >> You just do not understand Thompson. > > C99 6.7.7p3 says: > > A typedef declaration does not introduce a new type, only a > synonym for the type so specified. > > Is the standard wrong? > No, you are wrong. And since you snip away all my arguments there is no point in putting any more arguments. They will be snipped away anyway.
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-05-23 22:02 +0000 |
| Message-ID | <slrnitllvk.131i.usenet-nospam@guild.seebs.net> |
| In reply to | #4601 |
On 2011-05-23, Keith Thompson <kst-u@mib.org> wrote: > C99 6.7.7p3 says: > > A typedef declaration does not introduce a new type, only a > synonym for the type so specified. > > Is the standard wrong? FREQUENTLY! ... Although I think at this point you've finally convinced me; it's more accurate to refer to the things typedefs create as "type names". It's just that the error of thinking of them as types happens to encourage me to write better code. :) -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-05-24 00:10 +0200 |
| Message-ID | <irem09$8s9$1@speranza.aioe.org> |
| In reply to | #4607 |
Le 24/05/11 00:02, Seebs a écrit :
> On 2011-05-23, Keith Thompson<kst-u@mib.org> wrote:
>> C99 6.7.7p3 says:
>>
>> A typedef declaration does not introduce a new type, only a
>> synonym for the type so specified.
>>
>> Is the standard wrong?
>
> FREQUENTLY!
>
> ... Although I think at this point you've finally convinced me; it's more
> accurate to refer to the things typedefs create as "type names". It's just
> that the error of thinking of them as types happens to encourage me to
> write better code. :)
>
> -s
The PURPOSE of typedefs is to HIDE the underlying type so that
source code refers to it INDIRECTLY.
The purpose of that indirection is twofold:
(1) To highlight a CONCEPT of the program:
typedef double CustomerBalance;
(2) To make code portable by abstracting the underlying type
away. (size_t for instance)
Typedefs aren't just aliases. Of course technically they are, but their
purpose is portability and clarity.
Obviously this (as anything) can be carried away to ridiculous heights
like:
typedef char g_char;
typedef int g_int;
typedef short g_short;
like in the glib :-)
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-05-23 22:12 +0200 |
| Message-ID | <iref3o$ma4$1@speranza.aioe.org> |
| In reply to | #4582 |
Le 23/05/11 21:45, Seebs a écrit : > On 2011-05-23, Keith Thompson<kst-u@mib.org> wrote: >> Just a quibble: size_t may be exactly the same type as unsigned long, >> since a typedef merely creates an alias for an existing type, not >> a new and distinct type. plain char and signed char (for example) >> are distinct in a way that size_t and unsigned long (for example) >> are not. > > True. Although, possibly confusingly, there are places where it seems > that the thing a typedef creates is itself then called "a type". The > wording is a bit fuzzy. > > We all know what we mean, I think. You could say it several ways: > > Typedef does not actually create types; instead, it creates > names which refer to existing types. > > Typedef creates types, but those types are identical to existing > types and can be used interchangably with them. > > These appear to me to be essentially equivalent. I used size_t since structures and other definitions of new types are described later. Size_t has the good quality of being immediately comprehensible (size type) for a newcomer into the language... What bothers me is that I get never a discussion about the main argumentation of my posts but always "Just a quibble" and the we start discussing about small details that are just that: details What do you think of the two definitions (1) Functional (a type is an algorithm description) (2) Conceptual (A type embodies a concept in the program) And I think I am missing one: (3) A type implies a set of operations allowed with it. This would be different than (1) since (1) refers to calculating the "value" stored in a type. I am sure (3) is missing but can't really identify it yet as definitely distinct of (1).
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web