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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-06-07 19:50 +0200 |
| Message-ID | <4dee6486$0$38640$4fafbaef@reader1.news.tin.it> |
| In reply to | #4975 |
"Michael Press" <rubrum@pacbell.net> ha scritto nel messaggio news:rubrum-3AA665.21503928052011@news.albasani.net... > In article <slrnitlohk.15f2.usenet-nospam@guild.seebs.net>, > Seebs <usenet-nospam@seebs.net> wrote: > >> On 2011-05-23, Ian Collins <ian-news@hotmail.com> wrote: >> > gmp has been around for a long time, well before inline function support >> > was common in C compilers (or even standardised). >> >> More importantly: >> >> gmp is used by gcc. >> >> gcc has a strictly dogmatic requirement that you don't need a very good >> or modern compiler to build it. > > What is the dogma? one axiom > -- > Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-23 19:33 -0400 |
| Message-ID | <56d1adcc041e87f-81300@gmail.com> |
| In reply to | #4615 |
On Tue, May 24, 2011 at 10:35:48AM +1200, Ian Collins wrote:
> On 05/24/11 09:53 AM, Uncle Steve wrote:
> >On Tue, May 24, 2011 at 09:25:29AM +1200, Ian Collins wrote:
> >>On 05/24/11 08:51 AM, Uncle Steve wrote:
> >>>On Mon, May 23, 2011 at 07:45:24PM +0000, Seebs wrote:
> >>>>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.
> >>>
> >>>How about the idea that typedefs create aliases for the basic built-in
> >>>types supplied by the language spec.?
> >>
> >>A typedef may provide an alias to any existing type, built-in, user
> >>defined or even incomplete.
> >
> >There are no "user defined" types in C.
>
> If they aren't defined buy programmers, who are they defined by?
The compiler writers. See my recent reply to Peter Seebach.
> >Structures and unions are
> >aggregates of basic types (and structures/unions).
>
> Well if you want to be pedantic, unions aren't aggregate types because
> they can only contain one member at a time.
>
> Let's expand the above for completeness:
>
> A typedef may provide an alias to any existing type, built-in,
> aggregate, union, composite or even incomplete.
>
> There, did I leave anything out?
No, it seems very reasonable.
> >I believe
> >incomplete types are a (usually temporary) artifact of the compilation
> >process and you won't ever see them in a running program.
>
> Have you ever used void*? What about a library with an opaque handle type?
void * is a non-specific pointer, with special semantics contrasted to
normal pointer types. It is not "incomplete". Perhaps my internal
representation of "incomplete type" is wrong. I labor under the
delusion that a structure defined with an element whose type is not
known is incomplete:
struct incomplete {
int foo;
struct bar something;
};
until the compiler encounters a definition of "struct bar", struct
incomplete is precisely that, and cannot be used to define anything.
This produces an error if there is no struct bar definition because
the compiler cannot guess what code to generate. Hence, it would
never be encountered at run-time. Please correct me if this is not
the case.
> >BTW, have a look at the gmp.h header and note that they do not shy
> >away from macro-like functions. Not that I care a whole lot, but I'd
> >say the writers of the gmp library probably know more than you do
> >about the suitability of inline functions versus macros and when to
> >use each. Just a 'feeling' on the matter, which is not to say that
> >you're entirely wrong.
>
> gmp has been around for a long time, well before inline function support
> was common in C compilers (or even standardised).
I think they expect old platforms to use old versions of gmp.
Regards,
Uncle Steve
--
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-24 12:03 +1200 |
| Message-ID | <940aukFt2pU18@mid.individual.net> |
| In reply to | #4627 |
On 05/24/11 11:33 AM, Uncle Steve wrote:
> On Tue, May 24, 2011 at 10:35:48AM +1200, Ian Collins wrote:
>> On 05/24/11 09:53 AM, Uncle Steve wrote:
>>> On Tue, May 24, 2011 at 09:25:29AM +1200, Ian Collins wrote:
>>>> On 05/24/11 08:51 AM, Uncle Steve wrote:
>>>>> On Mon, May 23, 2011 at 07:45:24PM +0000, Seebs wrote:
>>>>>> 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.
>>>>>
>>>>> How about the idea that typedefs create aliases for the basic built-in
>>>>> types supplied by the language spec.?
>>>>
>>>> A typedef may provide an alias to any existing type, built-in, user
>>>> defined or even incomplete.
>>>
>>> There are no "user defined" types in C.
>>
>> If they aren't defined buy programmers, who are they defined by?
>
> The compiler writers. See my recent reply to Peter Seebach.
So if I write struct Point { int x,y; }; do I become a compiler writer?
The distinction you attempt to draw in the other reply is an artificial
one that does not apply to C.
>>> Structures and unions are
>>> aggregates of basic types (and structures/unions).
>>
>> Well if you want to be pedantic, unions aren't aggregate types because
>> they can only contain one member at a time.
>>
>> Let's expand the above for completeness:
>>
>> A typedef may provide an alias to any existing type, built-in,
>> aggregate, union, composite or even incomplete.
>>
>> There, did I leave anything out?
>
> No, it seems very reasonable.
Good, that's a start.
>>> I believe
>>> incomplete types are a (usually temporary) artifact of the compilation
>>> process and you won't ever see them in a running program.
>>
>> Have you ever used void*? What about a library with an opaque handle type?
>
> void * is a non-specific pointer, with special semantics contrasted to
> normal pointer types. It is not "incomplete".
See 6.2.5 p19.
> Perhaps my internal
> representation of "incomplete type" is wrong. I labor under the
> delusion that a structure defined with an element whose type is not
> known is incomplete:
>
> struct incomplete {
> int foo;
> struct bar something;
> };
It is, the compiler interprets "struct bar something;" as a forward
declaration of struct bar.
> until the compiler encounters a definition of "struct bar", struct
> incomplete is precisely that, and cannot be used to define anything.
Which is why we use a pointer member for incomplete types:
struct bar;
struct incomplete {
int foo;
struct bar* something;
};
> This produces an error if there is no struct bar definition because
> the compiler cannot guess what code to generate. Hence, it would
> never be encountered at run-time. Please correct me if this is not
> the case.
It is, but a pointer to an incomplete may be used.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-23 21:27 -0400 |
| Message-ID | <e086f8c7d12fb8d-c2f4b@gmail.com> |
| In reply to | #4634 |
On Tue, May 24, 2011 at 12:03:32PM +1200, Ian Collins wrote:
> On 05/24/11 11:33 AM, Uncle Steve wrote:
> >On Tue, May 24, 2011 at 10:35:48AM +1200, Ian Collins wrote:
> >>On 05/24/11 09:53 AM, Uncle Steve wrote:
> >>>On Tue, May 24, 2011 at 09:25:29AM +1200, Ian Collins wrote:
> >>>>On 05/24/11 08:51 AM, Uncle Steve wrote:
> >>>>>On Mon, May 23, 2011 at 07:45:24PM +0000, Seebs wrote:
> >>>>>>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.
> >>>>>
> >>>>>How about the idea that typedefs create aliases for the basic built-in
> >>>>>types supplied by the language spec.?
> >>>>
> >>>>A typedef may provide an alias to any existing type, built-in, user
> >>>>defined or even incomplete.
> >>>
> >>>There are no "user defined" types in C.
> >>
> >>If they aren't defined buy programmers, who are they defined by?
> >
> >The compiler writers. See my recent reply to Peter Seebach.
>
> So if I write struct Point { int x,y; }; do I become a compiler writer?
Perhaps, but only in your Special Place...
> The distinction you attempt to draw in the other reply is an artificial
> one that does not apply to C.
There's another one to look at as well, in which I attempt to clarify
the evident confusion over the terminology.
> >>>Structures and unions are
> >>>aggregates of basic types (and structures/unions).
> >>
> >>Well if you want to be pedantic, unions aren't aggregate types because
> >>they can only contain one member at a time.
> >>
> >>Let's expand the above for completeness:
> >>
> >>A typedef may provide an alias to any existing type, built-in,
> >>aggregate, union, composite or even incomplete.
> >>
> >>There, did I leave anything out?
> >
> >No, it seems very reasonable.
>
> Good, that's a start.
>
> >>>I believe
> >>>incomplete types are a (usually temporary) artifact of the compilation
> >>>process and you won't ever see them in a running program.
> >>
> >>Have you ever used void*? What about a library with an opaque handle
> >>type?
> >
> >void * is a non-specific pointer, with special semantics contrasted to
> >normal pointer types. It is not "incomplete".
>
> See 6.2.5 p19.
>
> >Perhaps my internal
> >representation of "incomplete type" is wrong. I labor under the
> >delusion that a structure defined with an element whose type is not
> >known is incomplete:
> >
> >struct incomplete {
> > int foo;
> > struct bar something;
> >};
>
> It is, the compiler interprets "struct bar something;" as a forward
> declaration of struct bar.
>
> >until the compiler encounters a definition of "struct bar", struct
> >incomplete is precisely that, and cannot be used to define anything.
>
> Which is why we use a pointer member for incomplete types:
>
> struct bar;
>
> struct incomplete {
> int foo;
> struct bar* something;
> };
>
> >This produces an error if there is no struct bar definition because
> >the compiler cannot guess what code to generate. Hence, it would
> >never be encountered at run-time. Please correct me if this is not
> >the case.
>
> It is, but a pointer to an incomplete may be used.
I see the logic, as pointers ought to be the same size regardless of
the thing they point to. But of what use is it to define an
incomplete pointer type? All you can do is suppress warnings by
casting any assignment to a complete type that the compiler knows
about.
Regards,
Uncle Steve
--
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-24 13:47 +1200 |
| Message-ID | <940h22Ft2pU21@mid.individual.net> |
| In reply to | #4645 |
On 05/24/11 01:27 PM, Uncle Steve wrote: > On Tue, May 24, 2011 at 12:03:32PM +1200, Ian Collins wrote: >> On 05/24/11 11:33 AM, Uncle Steve wrote: >> >>> This produces an error if there is no struct bar definition because >>> the compiler cannot guess what code to generate. Hence, it would >>> never be encountered at run-time. Please correct me if this is not >>> the case. >> >> It is, but a pointer to an incomplete may be used. > > I see the logic, as pointers ought to be the same size regardless of > the thing they point to. But of what use is it to define an > incomplete pointer type? All you can do is suppress warnings by > casting any assignment to a complete type that the compiler knows > about. I wrote "pointer to an incomplete type" (OK, I omitted "type"!). A pointer to an incomplete type is frequently used as an handle type to avoid exposing the type definition to the user. FILE* is the most obvious example. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-23 23:45 -0400 |
| Message-ID | <732fb0fb67c13d1-11215@gmail.com> |
| In reply to | #4648 |
On Tue, May 24, 2011 at 01:47:46PM +1200, Ian Collins wrote: > On 05/24/11 01:27 PM, Uncle Steve wrote: > >On Tue, May 24, 2011 at 12:03:32PM +1200, Ian Collins wrote: > >>On 05/24/11 11:33 AM, Uncle Steve wrote: > >> > >>>This produces an error if there is no struct bar definition because > >>>the compiler cannot guess what code to generate. Hence, it would > >>>never be encountered at run-time. Please correct me if this is not > >>>the case. > >> > >>It is, but a pointer to an incomplete may be used. > > > >I see the logic, as pointers ought to be the same size regardless of > >the thing they point to. But of what use is it to define an > >incomplete pointer type? All you can do is suppress warnings by > >casting any assignment to a complete type that the compiler knows > >about. > > I wrote "pointer to an incomplete type" (OK, I omitted "type"!). > > A pointer to an incomplete type is frequently used as an handle type to > avoid exposing the type definition to the user. FILE* is the most > obvious example. Ah, well that makes sense. I understand that it's good practise to insulate layers within the application to discourage users from relying on private data fields which might be implementation specific, arch specific, or which are moving targets in an actively developed project. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-24 00:07 -0700 |
| Message-ID | <lnboys1srt.fsf@nuthaus.mib.org> |
| In reply to | #4648 |
Ian Collins <ian-news@hotmail.com> writes:
[...]
> A pointer to an incomplete type is frequently used as an handle type to
> avoid exposing the type definition to the user. FILE* is the most
> obvious example.
FILE is specifically required to be an object type.
--
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-24 08:05 -0400 |
| Message-ID | <irg6ua$a1b$1@dont-email.me> |
| In reply to | #4627 |
On 05/23/2011 07:33 PM, Uncle Steve wrote:
> On Tue, May 24, 2011 at 10:35:48AM +1200, Ian Collins wrote:
>> On 05/24/11 09:53 AM, Uncle Steve wrote:
...
>>> There are no "user defined" types in C.
>>
>> If they aren't defined buy programmers, who are they defined by?
>
> The compiler writers. See my recent reply to Peter Seebach.
So, when I write
struct mystruct {
int hello;
float goodbye;
};
The definition of struct mystruct was actually provided by the compiler
writers? Even though the definition was written by me (who is only a
user), and never seen by the compiler writers? How exactly is this magic
performed?
>>> I believe
>>> incomplete types are a (usually temporary) artifact of the compilation
>>> process and you won't ever see them in a running program.
>>
>> Have you ever used void*? What about a library with an opaque handle type?
>
> void * is a non-specific pointer, with special semantics contrasted to
> normal pointer types. It is not "incomplete".
The standard defines void as "an incomplete type that cannot be
completed" (6.2.5p19).
> ... Perhaps my internal
> representation of "incomplete type" is wrong. I labor under the
> delusion that a structure defined with an element whose type is not
> known is incomplete:
>
> struct incomplete {
> int foo;
> struct bar something;
> };
Yes, your internal representation is wrong, and that is a delusion.
> until the compiler encounters a definition of "struct bar", struct
> incomplete is precisely that, and cannot be used to define anything.
Unless struct bar is already a complete type at the point where it is
mentioned in the above definition, it is a constraint violation (6.7.2.1p2).
Here are three canonical examples of incomplete types:
struct bar; /* Declares an incomplete type. */
extern int array[]; /* Declares an object with an incomplete type.*/
void *p; /* Defines an object with a complete type, that is a pointer to
an object with an incomplete type. */
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-05-23 19:54 -0500 |
| Message-ID | <ires4n$et7$1@dont-email.me> |
| In reply to | #4606 |
On 5/23/2011 4:53 PM, Uncle Steve wrote:
> On Tue, May 24, 2011 at 09:25:29AM +1200, Ian Collins wrote:
>> On 05/24/11 08:51 AM, Uncle Steve wrote:
>>> On Mon, May 23, 2011 at 07:45:24PM +0000, Seebs wrote:
>>>> 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.
>>>
>>> How about the idea that typedefs create aliases for the basic built-in
>>> types supplied by the language spec.?
>>
>> A typedef may provide an alias to any existing type, built-in, user
>> defined or even incomplete.
>
> There are no "user defined" types in C. Structures and unions are
> aggregates of basic types (and structures/unions). I believe
> incomplete types are a (usually temporary) artifact of the compilation
> process and you won't ever see them in a running program.
There are function types, too.
typedef struct {
char uncle[5];
} s_uncle;
typedef s_uncle * f_new_uncle(int, const char *, const s_uncle *);
static f_new_uncle new_uncle_unsafe;
f_new_uncle new_uncle;
That function type appears to be user-defined.
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-23 21:03 -0400 |
| Message-ID | <a1c7e744c9f0301-49174@gmail.com> |
| In reply to | #4631 |
On Mon, May 23, 2011 at 07:54:57PM -0500, Shao Miller wrote:
> On 5/23/2011 4:53 PM, Uncle Steve wrote:
> >On Tue, May 24, 2011 at 09:25:29AM +1200, Ian Collins wrote:
> >>On 05/24/11 08:51 AM, Uncle Steve wrote:
> >>>On Mon, May 23, 2011 at 07:45:24PM +0000, Seebs wrote:
> >>>>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.
> >>>
> >>>How about the idea that typedefs create aliases for the basic built-in
> >>>types supplied by the language spec.?
> >>
> >>A typedef may provide an alias to any existing type, built-in, user
> >>defined or even incomplete.
> >
> >There are no "user defined" types in C. Structures and unions are
> >aggregates of basic types (and structures/unions). I believe
> >incomplete types are a (usually temporary) artifact of the compilation
> >process and you won't ever see them in a running program.
>
> There are function types, too.
>
> typedef struct {
> char uncle[5];
> } s_uncle;
> typedef s_uncle * f_new_uncle(int, const char *, const s_uncle *);
> static f_new_uncle new_uncle_unsafe;
> f_new_uncle new_uncle;
>
> That function type appears to be user-defined.
Sure, but a function definition is not a basic type. It's another
special case for type-checking the arguments and return value of
functions. Call it an aggregate because it bears more resemblance to
a structure than an int.
BTW, would you use, say, k_thompson as a variable identifier when you're writing
examples in reply to Keith Thompson? Just curious.
Regards,
Uncle Steve
--
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-05-23 22:12 -0500 |
| Message-ID | <irf45o$nnp$1@dont-email.me> |
| In reply to | #4641 |
On 5/23/2011 8:03 PM, Uncle Steve wrote:
> On Mon, May 23, 2011 at 07:54:57PM -0500, Shao Miller wrote:
>> On 5/23/2011 4:53 PM, Uncle Steve wrote:
>>> On Tue, May 24, 2011 at 09:25:29AM +1200, Ian Collins wrote:
>>>> On 05/24/11 08:51 AM, Uncle Steve wrote:
>>>>> On Mon, May 23, 2011 at 07:45:24PM +0000, Seebs wrote:
>>>>>> 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.
>>>>>
>>>>> How about the idea that typedefs create aliases for the basic built-in
>>>>> types supplied by the language spec.?
>>>>
>>>> A typedef may provide an alias to any existing type, built-in, user
>>>> defined or even incomplete.
>>>
>>> There are no "user defined" types in C. Structures and unions are
>>> aggregates of basic types (and structures/unions). I believe
>>> incomplete types are a (usually temporary) artifact of the compilation
>>> process and you won't ever see them in a running program.
>>
>> There are function types, too.
>>
>> typedef struct {
>> char uncle[5];
>> } s_uncle;
>> typedef s_uncle * f_new_uncle(int, const char *, const s_uncle *);
>> static f_new_uncle new_uncle_unsafe;
>> f_new_uncle new_uncle;
>>
>> That function type appears to be user-defined.
>
> Sure, but a function definition is not a basic type.
Ok, but now you've said "basic type" rather than "\"user defined\" types".
Beyond that, the second typedef in the example is not a function
definition. It includes the definition of a function type.
The standard definition in C99, if I'm not mistaken, includes:
"The meaning of a value stored in an object or returned by a function
is determined by the /type/ of the expression used to access it..."
> It's another
> special case for type-checking the arguments and return value of
> functions. Call it an aggregate because it bears more resemblance to
> a structure than an int.
Well, "aggregate" goes more like this, if I'm not mistaken:
"Array and structure types are collectively called /aggregate types/."
I think that the best argument against "user-defined types" might go
more like:
"\"user-defined\" does not appear in such-and-such standard of C."
I think that when you are using "aggregate," that perhaps you mean
"derived."
"Any number of /derived types/ can be constructed from the object,
function, and incomplete types, as follows..."
>
> BTW, would you use, say, k_thompson as a variable identifier when you're writing
> examples in reply to Keith Thompson? Just curious.
He has previously and kindly offered that using his first name is
acceptable, so I'd probably use that. Other possibilities include
"foo", "bar", "baz", "cat", "dog".
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-24 00:03 -0400 |
| Message-ID | <c6df7e1de1fd10f-d35e5@gmail.com> |
| In reply to | #4650 |
On Mon, May 23, 2011 at 10:12:02PM -0500, Shao Miller wrote:
> On 5/23/2011 8:03 PM, Uncle Steve wrote:
> >On Mon, May 23, 2011 at 07:54:57PM -0500, Shao Miller wrote:
> >>On 5/23/2011 4:53 PM, Uncle Steve wrote:
> >>>On Tue, May 24, 2011 at 09:25:29AM +1200, Ian Collins wrote:
> >>>>On 05/24/11 08:51 AM, Uncle Steve wrote:
> >>>>>On Mon, May 23, 2011 at 07:45:24PM +0000, Seebs wrote:
> >>>>>>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.
> >>>>>
> >>>>>How about the idea that typedefs create aliases for the basic built-in
> >>>>>types supplied by the language spec.?
> >>>>
> >>>>A typedef may provide an alias to any existing type, built-in, user
> >>>>defined or even incomplete.
> >>>
> >>>There are no "user defined" types in C. Structures and unions are
> >>>aggregates of basic types (and structures/unions). I believe
> >>>incomplete types are a (usually temporary) artifact of the compilation
> >>>process and you won't ever see them in a running program.
> >>
> >>There are function types, too.
> >>
> >> typedef struct {
> >> char uncle[5];
> >> } s_uncle;
> >> typedef s_uncle * f_new_uncle(int, const char *, const s_uncle *);
> >> static f_new_uncle new_uncle_unsafe;
> >> f_new_uncle new_uncle;
> >>
> >>That function type appears to be user-defined.
> >
> >Sure, but a function definition is not a basic type.
>
> Ok, but now you've said "basic type" rather than "\"user defined\" types".
>
> Beyond that, the second typedef in the example is not a function
> definition. It includes the definition of a function type.
Ah, sorry. It's getting late and I'm misreading things.
> The standard definition in C99, if I'm not mistaken, includes:
>
> "The meaning of a value stored in an object or returned by a function
> is determined by the /type/ of the expression used to access it..."
Doesn't that specify when and how a cast occurs in expression
evaluation?
int function(void) {
return(42);
}
...
long v = function();
So what I gather from the quoted text is that the return value of
function() is promoted to long before the assignment occurs. Is that
correct?
> >It's another
> >special case for type-checking the arguments and return value of
> >functions. Call it an aggregate because it bears more resemblance to
> >a structure than an int.
>
> Well, "aggregate" goes more like this, if I'm not mistaken:
>
> "Array and structure types are collectively called /aggregate types/."
>
> I think that the best argument against "user-defined types" might go
> more like:
>
> "\"user-defined\" does not appear in such-and-such standard of C."
>
> I think that when you are using "aggregate," that perhaps you mean
> "derived."
>
> "Any number of /derived types/ can be constructed from the object,
> function, and incomplete types, as follows..."
Sure, I'm happy with 'derived'.
> >
> >BTW, would you use, say, k_thompson as a variable identifier when you're
> >writing
> >examples in reply to Keith Thompson? Just curious.
>
> He has previously and kindly offered that using his first name is
> acceptable, so I'd probably use that. Other possibilities include
> "foo", "bar", "baz", "cat", "dog".
It just seemed odd.
Regards,
Uncle Steve
--
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | pete <pfiland@mindspring.com> |
|---|---|
| Date | 2011-05-24 00:19 -0400 |
| Message-ID | <4DDB31B5.2795@mindspring.com> |
| In reply to | #4663 |
Uncle Steve wrote:
>
> On Mon, May 23, 2011 at 10:12:02PM -0500, Shao Miller wrote:
> > The standard definition in C99, if I'm not mistaken, includes:
> >
> > "The meaning of a value stored in an
> > object or returned by a function
> > is determined by the /type/ of the expression used to access it..."
>
> Doesn't that specify when and how a cast occurs in expression
> evaluation?
The quoted text is not about conversions.
If you have a signed char with a value of (-1)
and you convert that by assignment to unsigned char,
then the value in the unsigned char object will be
equal to UCHAR_MAX, on any computer.
signed char minus_one = -1;
unsigned char max = minus_one;
That's conversions.
But, if you access minus_one as an unsigned char
unsigned char access_value = *(unsigned char *)&minus_one;
then the value of access_value may or may not
be something different from UCHAR_MAX,
depending on the representation of ((signed char)-1).
That's not conversions.
--
pete
[toc] | [prev] | [next] | [standalone]
| From | pete <pfiland@mindspring.com> |
|---|---|
| Date | 2011-05-24 00:20 -0400 |
| Message-ID | <4DDB3225.5089@mindspring.com> |
| In reply to | #4664 |
pete wrote: > signed char minus_one = -1; > But, if you access minus_one as an unsigned char > > unsigned char access_value = *(unsigned char *)&minus_one; > > then the value of access_value may or may not > be something different from UCHAR_MAX, > depending on the representation of ((signed char)-1). > > That's not conversions. That's not a conversion of minus_one, anyway. -- pete
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-05-24 00:46 -0500 |
| Message-ID | <irfd7c$1en$1@dont-email.me> |
| In reply to | #4663 |
On 5/23/2011 11:03 PM, Uncle Steve wrote:
> On Mon, May 23, 2011 at 10:12:02PM -0500, Shao Miller wrote:
>> The standard definition in C99, if I'm not mistaken, includes:
>>
>> "The meaning of a value stored in an object or returned by a function
>> is determined by the /type/ of the expression used to access it..."
>
> Doesn't that specify when and how a cast occurs in expression
> evaluation?
>
No. That quotation is from here[n1256.pdf:6.2.5p1]. The slashes I
injected into the quoted text were intended to denote italics in the
original. For italics in the original, we have that "... Other terms
are defined where they appear in /italic/ type or on the left side of a
syntax rule. ..."[n1256.pdf:3p1] *
As far as I know, a cast occurs when one uses something like:
(type)expression
in code. Perhaps you were thinking of "conversion" rather than "cast"?
> int function(void) {
> return(42);
> }
>
Just out of curiosity, do you ever override the 'return' keyword with a
function-like macro? That's one possible reason for wrapping return
values with parentheses and it'd be interesting to get a sense of how
many people have that habit for that intention.
> ...
>
> long v = function();
>
> So what I gather from the quoted text is that the return value of
> function() is promoted to long before the assignment occurs. Is that
> correct?
>
Actually, I don't think so. I think that "...the value of the right
operand is converted to the type of the assignment expression and
replaces the value stored in the object designated by the left
operand."[n1256.pdf:6.5.16.1p2]
But anyway, in regards to "user defined types," because that doesn't
appear in a standard of C (or does it?), I think it's possible that it's
a subject where discussion can be challenging by having different
understandings of the term for different people.
I _think_ that what you have offered is congruent with "you, the
programmer, don't get to invent/specify a type which is not a derived type."
I _think_ what at least one other poster has offered is congruent with
"if you, the programmer, specify a derived type, then that type could be
called a youser^H^H^H^H^H^Huser-defined type, since _something_ defined it."
Or maybe not.
* I hope to some day purchase some actual standards. The efforts that
have gone into them can certainly save me some time == money while
attempting to write portable C. :)
[toc] | [prev] | [next] | [standalone]
| From | pete <pfiland@mindspring.com> |
|---|---|
| Date | 2011-05-24 07:36 -0400 |
| Message-ID | <4DDB982E.2E38@mindspring.com> |
| In reply to | #4671 |
Shao Miller wrote: > That's one possible reason for wrapping return > values with parentheses and it'd be interesting to get a sense of how > many people have that habit for that intention. Some code examples in the original K&R book are done that way. -- pete
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-24 10:58 -0400 |
| Message-ID | <46bfca6e0cc73cf-bd09a@gmail.com> |
| In reply to | #4671 |
On Tue, May 24, 2011 at 12:46:29AM -0500, Shao Miller wrote:
> On 5/23/2011 11:03 PM, Uncle Steve wrote:
> >On Mon, May 23, 2011 at 10:12:02PM -0500, Shao Miller wrote:
> >>The standard definition in C99, if I'm not mistaken, includes:
> >>
> >> "The meaning of a value stored in an object or returned by a function
> >>is determined by the /type/ of the expression used to access it..."
> >
> >Doesn't that specify when and how a cast occurs in expression
> >evaluation?
>
> No. That quotation is from here[n1256.pdf:6.2.5p1]. The slashes I
> injected into the quoted text were intended to denote italics in the
> original. For italics in the original, we have that "... Other terms
> are defined where they appear in /italic/ type or on the left side of a
> syntax rule. ..."[n1256.pdf:3p1] *
The full paragraph (from a draft version) is more compelling:
6.2.5 Types
#1
The meaning of a value stored in an object or returned by a
function is determined by the type of the expression used to access
it. (An identifier declared to be an object is the simplest such
expression; the type is specified in the declaration of the
identifier.) Types are partitioned into object types (types that
describe objects), function types (types that describe functions),
and incomplete types (types that describe objects but lack
information needed to determine their sizes).
> As far as I know, a cast occurs when one uses something like:
>
> (type)expression
>
> in code. Perhaps you were thinking of "conversion" rather than "cast"?
>
> >int function(void) {
> > return(42);
> >}
> >
>
> Just out of curiosity, do you ever override the 'return' keyword with a
> function-like macro? That's one possible reason for wrapping return
> values with parentheses and it'd be interesting to get a sense of how
> many people have that habit for that intention.
It's a cognitive semantic quirk. Return kind-of looks like it is a
special function that transfers control to the original caller, and so
I put return values in parenthesis because that's what you do with
real functions. I know it's not a function, but try to tell that to
my brain.
> >...
> >
> >long v = function();
> >
> >So what I gather from the quoted text is that the return value of
> >function() is promoted to long before the assignment occurs. Is that
> >correct?
> >
>
> Actually, I don't think so. I think that "...the value of the right
> operand is converted to the type of the assignment expression and
> replaces the value stored in the object designated by the left
> operand."[n1256.pdf:6.5.16.1p2]
>
> But anyway, in regards to "user defined types," because that doesn't
> appear in a standard of C (or does it?), I think it's possible that it's
> a subject where discussion can be challenging by having different
> understandings of the term for different people.
Indeed, and as real technical specifications typically use language
with more precision than colloquial written English, there is plenty
of room for misunderstanding between those who have differing degrees
of understanding.
> I _think_ that what you have offered is congruent with "you, the
> programmer, don't get to invent/specify a type which is not a derived type."
>
> I _think_ what at least one other poster has offered is congruent with
> "if you, the programmer, specify a derived type, then that type could be
> called a youser^H^H^H^H^H^Huser-defined type, since _something_ defined it."
>
> Or maybe not.
I was mostly taking issue with the idea that a derived type is
qualitatively equivalent to a /de-novo/ basic type, which was the
implication given in the way some were using the term 'type' in their
statements -- by my reckoning of their meaning. When the word 'type'
is used with precision similar to a word like 'run' ("the computer
runs"), it is difficult to be entirely sure what is really meant.
> * I hope to some day purchase some actual standards. The efforts that
> have gone into them can certainly save me some time == money while
> attempting to write portable C. :)
Actual printed copies are fairly expensive from what I gather.
Available from Global Engineering Documents, as per the C-FAQ, section
5.2.
Regards,
Uncle Steve
--
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-24 09:40 -0700 |
| Message-ID | <ln8vtwyrv5.fsf@nuthaus.mib.org> |
| In reply to | #4696 |
Uncle Steve <stevet810@gmail.com> writes:
> On Tue, May 24, 2011 at 12:46:29AM -0500, Shao Miller wrote:
[...]
>> Just out of curiosity, do you ever override the 'return' keyword with a
>> function-like macro? That's one possible reason for wrapping return
>> values with parentheses and it'd be interesting to get a sense of how
>> many people have that habit for that intention.
>
> It's a cognitive semantic quirk. Return kind-of looks like it is a
> special function that transfers control to the original caller, and so
> I put return values in parenthesis because that's what you do with
> real functions. I know it's not a function, but try to tell that to
> my brain.
Perhaps omitting the parentheses would help out with your brain
problem. 8-)}
Seriously, I don't use parentheses on return statements precisely
because a return statement is not a function call and I don't
want it to look like one. I do the same with sizeof: "sizeof obj"
rather than "sizeof(obj)".
[...]
>> I _think_ that what you have offered is congruent with "you, the
>> programmer, don't get to invent/specify a type which is not a derived type."
>>
>> I _think_ what at least one other poster has offered is congruent with
>> "if you, the programmer, specify a derived type, then that type could be
>> called a youser^H^H^H^H^H^Huser-defined type, since _something_ defined it."
>>
>> Or maybe not.
>
> I was mostly taking issue with the idea that a derived type is
> qualitatively equivalent to a /de-novo/ basic type, which was the
> implication given in the way some were using the term 'type' in their
> statements -- by my reckoning of their meaning. When the word 'type'
> is used with precision similar to a word like 'run' ("the computer
> runs"), it is difficult to be entirely sure what is really meant.
I believe you've misunderstood their meaning.
You seem to be seeing some ambiguity in the word "type". I don't
believe there is any such ambiguity; the word is well defined by the C
standard, and I think that most people here other than you have been
using it consistently and correctly.
There are basic types and derived types. Both basic types and derived
types are types. There are no user-defined basic types. There are
user-defined derived types. The statements "There are no user-defined
basic types" and "There are no user-defined types" are very different;
in particular, the first statement is true, and the second is false.
The following paragraph is the same as the previous with the
substitution of a few phrases.
There are men and women. Both men and women are people. There are no
pregnant men. There are pregnant women. The statements "There are no
pregnant men" and "There are no pregnant people" are very different; in
particular, the first statement is true, and the second is false.
>> * I hope to some day purchase some actual standards. The efforts that
>> have gone into them can certainly save me some time == money while
>> attempting to write portable C. :)
>
> Actual printed copies are fairly expensive from what I gather.
> Available from Global Engineering Documents, as per the C-FAQ, section
> 5.2.
I paid $18 for my PDF copy of the C99 standard from ansi.org; I think
it's $30 now. (You can also pay several hundred dollars for the same thing.)
Once you have the PDF, you can print it if you like, but I've
never bothered. But as I said elsethread, N1256 is better, for
most purposes, than the original C9 standard, and it's free.
--
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 | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-24 21:36 -0400 |
| Message-ID | <d2070619d410f23-efe81@gmail.com> |
| In reply to | #4709 |
On Tue, May 24, 2011 at 09:40:14AM -0700, Keith Thompson wrote:
> Uncle Steve <stevet810@gmail.com> writes:
> > On Tue, May 24, 2011 at 12:46:29AM -0500, Shao Miller wrote:
> [...]
> >> Just out of curiosity, do you ever override the 'return' keyword with a
> >> function-like macro? That's one possible reason for wrapping return
> >> values with parentheses and it'd be interesting to get a sense of how
> >> many people have that habit for that intention.
> >
> > It's a cognitive semantic quirk. Return kind-of looks like it is a
> > special function that transfers control to the original caller, and so
> > I put return values in parenthesis because that's what you do with
> > real functions. I know it's not a function, but try to tell that to
> > my brain.
>
> Perhaps omitting the parentheses would help out with your brain
> problem. 8-)}
Possibly, but I've decided on self-hypnosis as the cure. I'll get
back to you just as soon as I ... zzzzzzzzz.
> Seriously, I don't use parentheses on return statements precisely
> because a return statement is not a function call and I don't
> want it to look like one. I do the same with sizeof: "sizeof obj"
> rather than "sizeof(obj)".
You're correct, of course. And in the end, with the admission of
parenthetic infidelity, I reveal the fact that I was never taught
C or computer science by a qualified professional.
> [...]
>
> >> I _think_ that what you have offered is congruent with "you, the
> >> programmer, don't get to invent/specify a type which is not a derived type."
> >>
> >> I _think_ what at least one other poster has offered is congruent with
> >> "if you, the programmer, specify a derived type, then that type could be
> >> called a youser^H^H^H^H^H^Huser-defined type, since _something_ defined it."
> >>
> >> Or maybe not.
> >
> > I was mostly taking issue with the idea that a derived type is
> > qualitatively equivalent to a /de-novo/ basic type, which was the
> > implication given in the way some were using the term 'type' in their
> > statements -- by my reckoning of their meaning. When the word 'type'
> > is used with precision similar to a word like 'run' ("the computer
> > runs"), it is difficult to be entirely sure what is really meant.
>
> I believe you've misunderstood their meaning.
I must have, because the reaction to my comments were fairly strongly
worded.
> You seem to be seeing some ambiguity in the word "type". I don't
> believe there is any such ambiguity; the word is well defined by the C
> standard, and I think that most people here other than you have been
> using it consistently and correctly.
The "standard definition" doesn't seem to be the obvious one to
colloquial English speakers, but then we normally expect less rigor in
casual conversation.
> There are basic types and derived types. Both basic types and derived
> types are types. There are no user-defined basic types. There are
> user-defined derived types. The statements "There are no user-defined
> basic types" and "There are no user-defined types" are very different;
> in particular, the first statement is true, and the second is false.
With you so far.
> The following paragraph is the same as the previous with the
> substitution of a few phrases.
>
> There are men and women. Both men and women are people. There are no
> pregnant men. There are pregnant women. The statements "There are no
> pregnant men" and "There are no pregnant people" are very different; in
> particular, the first statement is true, and the second is false.
>
> >> * I hope to some day purchase some actual standards. The efforts that
> >> have gone into them can certainly save me some time == money while
> >> attempting to write portable C. :)
> >
> > Actual printed copies are fairly expensive from what I gather.
> > Available from Global Engineering Documents, as per the C-FAQ, section
> > 5.2.
>
> I paid $18 for my PDF copy of the C99 standard from ansi.org; I think
> it's $30 now. (You can also pay several hundred dollars for the same thing.)
> Once you have the PDF, you can print it if you like, but I've
> never bothered. But as I said elsethread, N1256 is better, for
> most purposes, than the original C9 standard, and it's free.
The addendum in its original form is probably only of interest to
language historians. I don't know if I'd like to pay for a PDF
version, but a smartly bound printed copy would be a nice thing to
have.
Regards,
Uncle Steve
--
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2011-06-01 16:33 -0400 |
| Message-ID | <fp7du61a6geh7cmo6uent35t92as8a6p31@4ax.com> |
| In reply to | #4709 |
On Tue, 24 May 2011 09:40:14 -0700, Keith Thompson <kst-u@mib.org> wrote: <snip: re C99 standard> > I paid $18 for my PDF copy of the C99 standard from ansi.org; I think > it's $30 now. (You can also pay several hundred dollars for the same thing.) As I understand the process, not *quite* the same thing. The only difference between the >300USD ISO version and the 30USD INCITS version is supposed to be the paragraph on the cover page which says, in effect, "approved by (I)NCITS". To programmers and implementors that makes no difference; to people in a contract lawsuit it might. > Once you have the PDF, you can print it if you like, but I've > never bothered. But as I said elsethread, N1256 is better, for > most purposes, than the original C9 standard, and it's free. Concur; for free=gratis not libre. Committee docs are still copyright, and if you tried to go into business selling it, or worse selling a modified version and calling it standard, I bet you'd be in trouble. But for the purpose of asserting or refuting statements of the form '$X is standard C', which is (part of) our topic here, yes it's fine.
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web